I have developed a graphql server with laravel (https://github.com/Folkloreatelier/laravel-graphql). Now I would like to create a React application by using Relay. When I create my first component, then I receive the error:
Uncaught Error: Invariant Violation: RelayQL: Unexpected invocation at runtime. Either the Babel transform was not set up, or it failed to identify this call site. Make sure it is being used verbatim as Relay.QL.
I still googled the error and I recognized that I need to install the Babel Relay Plugin. But to include this plugin I have to specify a schema. But I still have specified this schema on server side, why do I need this also in client side? Is there any example how to implement this when a server is still implemented (external server, e.g. no NodeJS server).
Thank you for your advice.
The schema for your data on the server-side is required by babel-relay-plugin to do transpilation of Relay.QL fragments in Javscripts that will be delivered to the client-side. However, note that on your GraphQL server, you define the schema in Laravel GraphQL PHP classes, which you need to convert it into JSON format that babel-relay-plugin expects.
For example, I did a similar setup with Rails and graphql-ruby (https://github.com/nethsix/relay-on-rails).
Define the data schema on my server-side using graphql-ruby classes in app/graph directory
Convert the schema into a JSON file using a script lib/tasks/graphql.rake, which I then stash into app/assets/javascripts/relay/data/schema.json
Point to the schema.json in your babelRelayPlug.js file wherever it is (mine is in assets/javascripts/relay/utils/babelRelayPlugin.js)
For Rails, we can easily dump the graphql-ruby schema to json by just calling #to_json method. You may have similar methods in PHP.
I compared the difference between setting up Relay on a nodejs server, vs. a non-nodejs server using an illustration here if it helps (https://medium.com/#khor/relay-facebook-on-rails-8b4af2057152)
Related
I'm a little new to GraphQL and this question falls under "It cannot possibly be this hard. I have to be missing something."
I have a fairly standard GraphQL/Apollo/React application split into client and server. Everything is working well with the client making API calls and getting data back from the server. The client is even able to upload files to the server. However, I now need the server to stream back files saved on disk. That's it.
This is the "I have to be missing something" part. Everything I've seen in the docs and on Stackoverflow is some variation of pushing the file back from the server and through the GraphQL query as a base64-endocded string and then doing some very hacky stuff on the client, often involving a hidden href tag and a simulated click. To this I say, "What???"
Seriously. There are files on disk that the server knows how to find. The client needs to show a button to the user that they can click on to download the file. That's it. Every other framework in every other language has an easy way to do this. Can someone show me the incredibly simple thing that I'm missing here?
Thanks,
Alex
What you're missing is that GraphQL really shouldn't be used for this purpose.
While GraphQL itself does not specify a specific format for serializing responses, the de facto format is JSON. And the only way to get the file inside a JSON response is if it's serialized as a string.
If you want to serve static content, you should set up Nginx, Apache or another web server that's been built with that in mind. Alternatively, if you're already using some existing web server library like Express, it most likely has tools for serving static content as well.
Just because you have a GraphQL endpoint does not necessarily mean it should be the only way your client communicates with your backend.
I'm transitioning towards more responsive front-end web apps and I have a question about model validation. Here's the set-up: the server has a standard REST API for inserting, updating, retrieving, etc. This could be written in Node or Java Spring, it doesn't matter. The front-end is written with something like Angular (or similar).
What I need is to figure out where to put the validation code. Here's the requirements:
All validation code should be written in one place only. Not both client and server. this implies that it should reside on the server, inside the REST API when persisting.
The front-end should be capable of understanding validation errors from the server and associating them to the particular field that caused the error. So if the field "username" is mandatory, the client can place an error next to that field saying "Username is mandatory".
It should be possible to validate correct variable types. So if we were expecting a number or a date and got a string instead, the error would be something like "'Yo' is not a correct date."
The error messages should be localized to the user's language.
Can anyone help me out? I need something simple and robust.
Thanks
When validating your input and it fails you can return a response in appropriate format (guessing you use JSON) to contain the error messages along with a proper HTTP error code.
Just working on a project with a Symfony backend, using FOSRestBundle to provide proper REST API. Using the form component of Symfony whenever there's a problem with the input a well structured JSON response is generated with error messages mapped to the fields or the top level if for example there's unexpected input.
After much research I found a solution using the Meteor.js platform. Since it's a pure javascript solution running on both the server and the client, you can define scripts once and have them run on both the client and the server.
From the official Meteor documentation:
Files outside the client, server and tests subdirectories are loaded on both the client and the server! That's the place for model definitions and other functions.
Wow. Defining models and validation scripts only once is pretty darn cool if you ask me. Also, there's no need to map between JSON and whatever server-side technology. Plus, no ORM mapping to get it in the DB. Nice!
Again, from the docs:
In Meteor, the client and server share the same database API. The same exact application code — like validators and computed properties — can often run in both places. But while code running on the server has direct access to the database, code running on the client does not. This distinction is the basis for Meteor's data security model.
Sounds good to me. Here's the last little gem:
Input validation: Meteor allows your methods and publish functions to take arguments of any JSON type. (In fact, Meteor's wire protocol supports EJSON, an extension of JSON which also supports other common types like dates and binary buffers.) JavaScript's dynamic typing means you don't need to declare precise types of every variable in your app, but it's usually helpful to ensure that the arguments that clients are passing to your methods and publish functions are of the type that you expect.
Anyway, sounds like I've found the a solution to the problem. If anyone else knows of a way to define validation once and have it run on both client and server please post an answer below, I'd love to hear it.
Thanks all.
To be strict, your last gate keeper of validation for any CRUD operations is of course on server-side. I do not know what is your concern that you should handle your validation on one end only(either server or client), but usually doing on both sides is better for both user experience and performance.
Say your username field is a mandatory field. This field can be easily handled in front-end side; before a user click submit and then been sent to the server and then get returned and shows the error code. You can save that round trip with a one liner code in front-end.
Of course, one may argue that from client-side the bad guys may manipulate the data and thus bypassing the front-end validation. That goes to my first point - your final gate keeper in validation should be on your server-side. That's why, data integrity is still the server's job. Make sure whatever that goes into your database is clean, dry and valid.
To answer you question, (biased opinion though) AngularJS is still a pretty awesome framework to let you do front-end validation, as well as providing a good way to do server-side error handling.
I'm trying to develop AngularJS applicatino using the Angular tutorial web-server script.
Is it possible or smart to use it for development only scenario ?
I want to be able to develop and test my Angular application without relying on the real server and real database, that's the reason I'm asking this.
I don't know much about the tutorial web-server script.
When it comes to your situation, though, your best bet is to abstract away your data managing processes. In other words, you can make a set of services that take care of loading and saving your data. You could have methods like book.save() or book.fetch().
Then in save() and fetch() you can return or insert an object literal or call for a JSON file.
Assuming that your product will be running on JSON data, you should be able to write another set of model services that call JSON data from the server rather any that you've hard written in the code or in a *.json file.
I want to make database queries in my Jersey REST webapp. The ideal situation would be to find a way where the database connection is initialised once at the first app run. Afterwards I only get the instance of DAOFactory object in my REST class and make the queries in the methods. I am using mysql connector. Is there a way to find a way to do it in Jersey? In JSF it was possible - I just used an application-scoped bean when I run the code. Moreover it would be good if I could access the ServletContext object inside this method cause I would like to use it's getResourceAsStream() method to read the database connection parameters from WEB-INF/dao.properties file. But the 'only once per app initialisation' is the crucial part here.
I am building a little app that has to communicate with a MongoDB database. Of course there is a web service in front of the DB and I am not trying to access the DB directly from silverlight. At first I thought to have this service return BSON objects in order to have the client manage them.
Is this even possible? It seems like I can't even add the BSON driver's dlls to the Silverlight app (they disappear from References immediately after closing the Add reference dialog, which seems to indicate they are not compatible with Silverlight).
Or maybe I got totally lost and misunderstood it all?? It's my first attempt with MongoDb...
Thanks!!
Why would you want to manipulate BSON objects on the client?
I'd say: let mongodb driver deal with BSON, then convert data to a more usable format (JSON / XML or similar) and pass it to silverlight client.
This is better because:
Client doesn't know about underlying database. What if BSON format got upgraded? You would have to recompile and deploy all clients.
Client doesn't know about underlying database. It communicates with the server using its own JSON (XML) based protocol. You might be able to even switch DB to MySQL and clients won't notice.