We are currently developing an online shop for products in node.js. We use GraphQL in our backend. Now we would like to offer REST for our customers in addition to GraphQL. What would be the fastest and most effective solution for this problem?
When designing REST APIs one should start from database tables aka persistent entities and there are too many ways and frameworks.
When you have GraphQL already in place you may want your REST API to be somewhat similar, but I bet that made things more complicated, while pure REST evolved as simple HTTP implementation.
In face HTTP standard and REST standard have the same author(s).
Related
We're very familiar with IBM's Loopback and we're exploring/comparing NestJS as an alternative.
First and main topic: One feature that has always been an overall pleasure to work with is Loopback's built-in REST API's for its models together with the GraphQL-like querying that is supported both in the TypeScript API and as part of the REST API's themselves. It's been a pleasure to be able to include as many levels of depth of related entities as we like, add in other filtering and limit/scope to include certain fields. (This gives a gist of the feature: https://loopback.io/doc/en/lb4/Include-filter.html)
Is this possible to achieve in the NestJS world? I see a RelationalQueryBuilder for NestJS that is built-in (https://orkhan.gitbook.io/typeorm/docs/relational-query-builder) but I don't see it connected to a built in REST API and it looks a bit less sophisticated with its relations querying capability. Here are some decorators for CRUD REST in NestJS, but without the querying support (https://github.com/nestjsx/crud/wiki/Controllers#api-endpoints).
Also mature polymorphic relations support in Loopback seems like a strong differentiator for Loopback vs. an emerging extension for polymorphic relationships in NestJS (https://github.com/bashleigh/typeorm-polymorphic... thank you bashleigh!). Any success/thoughts opinions here?
How is working with MongoDB with NestJS (and TypeORM or Mongoose are the options)?
It seems like the first feature and main topic (built-in REST API's with fluent querying) may be one that really sets Loopback apart.
I am reading a book about GraphQL, and they claim that one strong point of GraphQL is selecting a field from the database. See sample below:
On this image, they selected just the title from the movies on the database. I can do the same using mongoose, using "select".
Could I say that mongoose is already GraphQL?
One is a query language that can be resolved by reaching into databases and gathering data, the other is a friendly wrapper that helps you interact with MongoDB, a NoSQL database.
You cannot say that it is already GQL because it does not deal in GraphQL language, it deals in JS queries. They are different languages with different syntaxes.
You might write a resolver for a GraphQL query using Mongoose, but they are still 2 separate things.
After I have asked the question, I gave some thoughts on the matter, indeed, as said zero298, they are two different things. Here, they build a app using both technologies, and justify the reasons it is better.
An excerpt from the aforementioned article:
"GraphQL is a technology that helps developers across the board to build more robust software more quickly. The ability to request all of the information you need in a single request is a game-changer. It has simplified my backend development of APIs for consumption by mobile and web applications that would normally rely on RESTful APIs. A normal RESTful API may have several endpoints for various entities (e.g. users, submissions, etc.); with GraphQL, you can get all of this information in a single go using GraphQL’s query language, also known as GQL."
I adding this extra answer as so if somebody falls into the same trap, they can easily get out!
Related question:
Do I need mongoose with graphql?
GraphQL with mongoose
As I understand it's possible graphql with rethinkdb. You can use graphql to query really any data set as its just the middleware really. What issues do I need to watch out for in this implementation? Server will be node.js in my case.
Documentation / examples of others doing this seam lacking.
I'm using GraphQL together with RethinkDb and don't see any particular problems in using them together compared to an implementation of a rest api or using mongo etc.
Here are two github projects using GraphQL and RethinkDb (the first one is more lightweight):
Isomorphic Material Relay Starter Kit
meatier
I am now building a native mobile application in Nativescript, leveraging my JS knowledge.
So, I though to switch to some other Nodejs framework.
My app's backend requirements will be:
pure JS
complete backend logic (i.e. controller)
connect to a MongoDB database
RESTful
non-frontend-dependent
non-DOM-dependent
easy-yet-complete to use: should be a framework which gives strong foundations to make a solid and efficient backend for a (relatively) inexperienced backend developer (except for Java basics and experience with pure PHP)
I was considering using my existing knowledge of Meteor but I can't implement any existing experiment of using ddp and websockets in it.
Some of the possibilities I was considering to give a try to:
Loopback
Total.js
Hapi.js
Sail.js
I am fine with any JS-based framework, whether it's NodeJS based or not
I am also open to a REST API solution which exposes Meteor backend, as long as is doesn't require ddp to be usable (it's not very clear to me what are the limits of non using DDP when using Meteor)
Any concrete advice, which would eventually avoid me trying all of them, before discovering they don't work with Nativescript or don't satisfy my requirements?
SailsJs is a wrapper around express.js with many add-ons and shortcuts that eases your life and shortens the code required to write, and it's very much suitable to write RESTful apps.
HAPI and Total, I didn't use them myself, but there are very good reviews about them, but when it comes to Sails, it's the highest in popularity, hence, better tested and used, which leads to a more mature framework over the time.
Loopback is good, but it requires payment at some point of usage, and still Sails is more popular.
Meteor.js is great, but it's not the right tool for that job, and it might take you more effort to make it as an easy to use RESTful framework, not to mention the un-needed memory and processing overhead, which has it's uses, but not in RESTful case. I tried to use it to write RESTful apps but didn't feel the ease and the low memory footprint as I experienced with express and Sails.
Update
Sails has clear and easy to use MVC style, with a command line to generate apis, configure-and-fine-tune-later APIs style, which is very much needed in prototyping and PoC applications, as well as short time to market.
Update 2
Sails ORM supports both SQL and NoSQL DBs, with dozen of supported drivers out there
First of all, I have seen this question: How to best create a RESTful API in Node.js and it has pointed me towards mers, which has been a great help.
But I have also been reading a lot of good things about derbyjs and it does look really interesting.
So my questions, does it make sense to use derbyjs for ceating a REST API (real-time features might be useful in the future, but not a 100% certain at this pont.)? And is it any better or worse than mers?
I am really grateful for any help.
Edit:
If anyone is interested, decided now to use sails.js: http://sailsjs.org/
The strength of Derby is that the same views (i.e. rendering templates into HTML) can be executed on the client as well as on the server. So for building a webapp, you won't have to explicitly code a REST API and then use it from the client-side JavaScript, instead you just write your views and Derby does the rest.
So if you're looking into making a REST API only (as your question states) and no HTML, there is no advantage in using Derby. It's the wrong tool for the job.
It depends on what you're looking for exactly. Derby.js is built on top of Express.js which has excellent support for creating a REST API. This also means that anything you can do in Express, you could also do in Derby. If you want real-time features, and the ability to build out a REST API, Derby.js is an excellent choice. It's also one of the reasons that people recommend Derby over something like Meteor (currently Meteor does not have support for REST endpoints, but it will hopefully in the future so also something you might want to keep your eye on, if you're in the market for real-time framework). However, if you're not looking for a node framework with an emphasis on real-time functionality, Derby is not the right choice. I would however recommend looking into Express.js to build a REST API. We use it currently for that purpose and it works really well. There are also a number of libraries and packages that play nicely with Express, so in the future if your needs change, it's easy to find something that works well with Express.
Anyway, I would recommend checking out some basic tutorials for how to create a REST API in Express because once you're able to successfully do that, adding some of the real-time features of Derby.js is fairly straightforward.
Basic tutorial on creating a REST API in Express.
http://coenraets.org/blog/2012/10/creating-a-rest-api-using-node-js-express-and-mongodb/