I am now about knee-deep in a new Gatsby 4 project and may have hit a wall. I can't figure how to do CRUD in Gatsby with Sanity as my backend. Can I do GQL mutations in Gatsby GraphQL? I can't find any examples or tutorials anywhere.
I have done this in Next.js in a different project a but my backend was very different in my new project.
Any help is great.
I do not agree with #fstr's answer. All you can do in React can be done in Gatsby since it's a React-based framework.
if you mean using Gatsby data layer and by that the graphql portion of
it to apply a crud functionality in your site, then no. Gatsby's data
layer is a "one way street" it's designed to pull in data, if you want
to use mutations and/or subscriptions, you'll have to use something
like Apollo to handle the mutations aspects of the data.
This means that Gatsby fetches and gathers the data from the sources (like Strapi) when it builds the site (that's the one-way). The only thing you need to take into account is that because of Gatsby's staticity, you won't be able to create new pages on-demand (or on-the-fly) based on the user's input for example. If that's your scenario, you will need to trigger webhooks or to serve the site in the server, as Next and Gatsby v4 does.
If your use-case is, for example, display some database (or Strapi) fields, manipulate/mutate them based on some user's actions/inputs, and fetch them again to display them on the screen you can easily do using any Apollo implementation as this article, and many other, explains (Implementing CRUD in web application using React and GraphQL). In this case, you won't be taking many benefits of using Gatsby rather than any other CRA or React site, but it can be done either way.
So summarizing:
If you want to create dynamic pages based on some user's action, Gatsby won't help you much because you'll need to rebuild the site again, so it won't bypass the staticity.
If you want to mutate some data, send them back to the server, and display them again, it can be easily done.
If you mean modify your data stored in Sanity via Gatsby and then get Gatsby to show the updates in real-time (faster than rebuilding the whole site), this isn't something Gatsby will help you with as far as I know. Relevant:
https://github.com/gatsbyjs/gatsby/issues/22012
if you mean using Gatsby data layer and by that the graphql portion of it to apply a crud functionality in your site, then no. Gatsby's data layer is a "one way street" it's designed to pull in data, if you want to use mutations and/or subscriptions, you'll have to use something like Apollo to handle the mutations aspects of the data.
and
This is a good question! Gatsby data layer exists only during build time. After that, it is transformed into HTML and plain JSON files which you can deploy as a static site.
So at the moment if you want to use Apollo on the client, you need a separate GraphQL server.
Sanity does have an API you can use to modify data though:
https://www.sanity.io/docs/http-mutations
Related
I am writing a web app in WebStorm based on GraphQL. The web app is comprised of two components (i.e. frontend and backend). On the backend, I am using makeExecutableSchema to create multiple schemas and then merging them together to help maintain my code.
The frontend relies on a WebStorm plugin called JS GraphQL that helps interpret GraphQL mutations and queries as described here. The plugin expects to see a .graphql file to understand typedefs. I can manually copy/paste information from the backend to the frontend directories. Ideally, I would automatically generate the .graphql file for the frontend during the backend coding. Does anyone have insight on how to accomplish this?
Have you looked into graphql-code-generator? It has a plugin architecture and so can be adapted to a variety of needs. I've been on teams that have used it successfully on a few projects, and it's not hard to hook up to CI or whatever.
I have created Web API.I know the Main advantage of Web API is cross domain application (I can call Web API in all platform). My question is ,Is there any performance issue When I call Web API in ASP.net WebForm???
I would like to know the below scenario
1.I Can use Direct SQL Query in .aspx Page
2.I Can use Web API and generate JSON to DataTable
I would like to know which one is fast and better to use.......
I have tried in JQuery,the performance is fine but I would like to call in ASP.net WEb Form
Where you call the API from or from what type of app makes no difference. Your issues are going to come from how you use it and what you do with the results of the calls.
Yes, you can get JSON data from the API and yes you can convert that to a DataTable, technically no issue there, but the performance will depend on how much data you retrieve in one go and how many transformations you go through to get it to the state you need for your webforms controls.
You're talking about using a dead tech ( webforms ) and trying to fit some things into how that works, which while possible, is not really the way to build anything these days.
SQL in aspx kinda says it all.Assuming you have an old app, that you just do updates to then just do what you can, but I would start looking into modern ways of building web apps. You don't have to keep using webforms controls anymore.
You can't talk about scalability when you still have stuff thrown in aspx pages. You need to start thinking about a proper separation of concerns, think about testing your stuff, retrieving only the data you need etc etc. Just because you add WebApi in the mix, that doesn't mean you'll get all the benefits, if everything else does not catch up to the required standard.
There is no inherent performance issue with using WebAPI, aside from the overhead of an additional network hop.
In real world terms, I think this would be negligible and outweighed by the benefits:
You get the 'cross platform' benefit you mentioned.
Better scalability as your 'service' and 'web' concerns are seperated and can be scaled appropriate to the load they need to serve.
The service layer functionality is re-useable, for example if you wanted to develop an app later.
I am starting to write my first web app with Node.js and Express. I have two approaches in mind.
Create two sets of routes. One that sends JSON, one that renders the page using a templating engine
Create a static website that makes API calls to the backend using AJAX, and have only routes for the API.
I understand that approach #2 depends on AJAX support in the browser, but if this was your project, based on the advantages and disadvantages of each approach, which would you choose and why?
If I am reading it right, both options #1 and #2 first set of routes is an API that returns JSON rather than sends it.
Assuming that in #2 you wouldn't create static pages with JavaScript doing AJAX calls, but rather still use express static routing like app.use('/', express.static(path.join(__dirname, 'dist'))); the difference between 2 approaches isn't that big.
Unless you already know some supported template language, such as mustache the cons are that you have to learn one and before that pick one (which isn't always an easy task from my experience!).
If you don't know one, depending on your application, you might still benefit from learning and using one. As an example you can think of a very generic UI where a single template could be reused very many times - like a generic database UI similar to, say well known phpmyadmin.
In case of static routing, you can achieve similar results by using a JavaScript framework which has components or templates, such as angular. If you aren't planning to use one, that could result in a lot of code duplication of otherwise re-usable widgets. And even when using one I can imagine a case when template engine would result in less code (or less files in your project at the very least). Not sure though if it's going to be easier to navigate and moreover to cover with tests when the project grows.
Without knowing more about your project it is hard to give more advice.
If the product you're developing is primarily static content with some dynamic pieces here and there, I'd recommend serving HTML from your backend via a templating system. A good example of this would be a blog. You'll end up with better SEO and there are less moving pieces to grok in this approach.
However, if you want to develop a single page application, I recommend using your backend entirely as an api, and writing your client side logic entirely in React/Vue/Angular/whatever. Single page applications have their front ends written entirely in javascript, and are best suited to highly dynamic, "app like" experiences online. Think gmail or facebook.
In my current project we use both approaches. Many views are static and data is obtained from API calls (we just use angular) or bootstrapped values (we load some objects with template, like user roles etc.)
However, some views are rendered on server site, because it easily allow us to dynamically inject values, tokens or other supporting data without making extra requests.
So, I vote for flexibility
I have a question about proper or recommended way of loading a lot of data from database. I have Laravel 5.4 project with Vue.js 2.0. I need display employees table from database on a page. On client Vue component is used for requesting this data with promise and build grid with vue-tables-2.
The problem in case that i can't find proper way for logic. There is already 50 000+ records and will be more. So using Employees::all() is really bad idea. Data is requested with axios from api url. And there is no possibility of using reddis or memcached. Looks like i need some kind of lazy loading post request from client and maybe with Laravel pagination. I will request first part of data and make next request to paginator with next post... and will have spam of requests.
If i will use default caching mechanism i don't understand how to build logic of caching, how to detect that model was changed and cache require rebuilding.
Maybe there is a way to organize lazy loading of data with dynamically add it into table and if user start search or filter before loading finished make request to server for direct database search. But again in this case possibly i will have a lot of database requests.
So question is - maybe there is a recommended way for organization stuff like this ?
React's website states:
Lots of people use React as the V in MVC.
From this, I am inferring that React does not play the "M" and the "C" roles in MVC.
If this is correct, it means one cannot build an entire web application solely with React JS.
Then, how?
Does React require a complete MVC framework for the backend, such as Rails or Laravel?
Can React simply pull data from a backend where a framework, such as Rails or Laravel, would be setup as a web API?
Does React not need any of this and works in a totally different way (in other words: am I completely missing the point)?
MVC is just a term for structuring data flow in an application.
You do not need MVC to build an application, even if it might help.
What React does is that it specializes in building isolated components - where the data flows in a single direction(the von neumann model of computing).
This is very nice because you can build an application with the premise that everything is always rerendered when data is changed, thus avoiding hard to read "two way bindings".
The thing is that it's very inefficient to rerender every view when some minor data is altered, but Reacts "Shadow DOM" optimizes this process, and makes efficient rerenders.
But React does not care where it gets data from. You could build a backend with nodejs/php/ruby or whatever you want. How you communicate and send data between the frontend and the backend is also left up to you. You could use jquery/socketio/superagent or whatever you want.
You can also combine React with any other framework, or just skip frameworks all together and fetch the data directly from a react component.
Facebook, the creators of React, have their way or organising projects called flux, which plays well with react(even if it is not needed).
https://github.com/facebook/flux