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
Related
I just started GraphQL via tutorial and a question remains unanswered.
I intend to create an API with PostgreSQL that would be consumed by my graphQL instance but I have a question.
I have always done REST and used an MVC architecture and I wonder if it is not overkill to create methods and a router to ultimately transform them back via graphQL?
I intend to consume my API for an application in VUEJS and on mobile fluttering.
Does anyone have any advice to better prepare my API and not be redundant?
thanks in advance
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
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).
I'm new to the full stack javascript application development, have read a lot of posts and documentation to all sorts of things but am a bit stuck on the following issue:
There are two frameworks that seem to offer quite similar functionality but are never contrasted against one another on the internet (as far as I could tell)
SailsJS - server side MVC framework built on Express
BreezeJS (+AngularJS) - client side MVC
Apparently I can combine Sails with Angular, there are a few attempt in NPM but none using Breeze in addition, is that due to redundancy or is it just a stupid idea?
I was thinking of developing a SPA that has computation intensive backend processes ( e.g. machine learning on large data sets ~ millions of mongo documents ) on something like
Mongo - Node : { Express - Sails } - Breeze - Angular
I'm looking for feedback on whether this kind of stack (particularly the Breeze / Sails part) is a bad idea or not. Also I'm really thankful for any advice / links to advice on javascript full stack architecture design decisions.
Thanks!
Basically, all the software you have mentioned can be used in one product. It's the important though to understand the purpose/strength of each component:
1. MongoDB
This one is pretty clear: database engine.
2. Node.js
This one too: server-side Javascript which will power your API.
3. Express.js
Now it's getting more interesting. Express is a server-side web-application framework for Node.js, but a very minimalistic one, which means it provides some basic functionality, no hidden magic and other fancy stuff.
4. Sails.js
On the contrary, Sails provides a lot of magic, starting with the API out of the box and ending with sockets. Even though it's built on top of Express, Sails is a server-side Javascript framework which follows a completely different approach, with convenience over simplicity. If we talking about a SPA, then the most useful thing Sails has to offer is, definitely, API out of the box: you'll be able to get it up and running in less then 5 minutes.
5. Angular.js
Here we are getting onto the client side. Angular helps you better organize your client-side Javascript and easily perform some pretty complex tasks in the browser. And, of course, Angular (or a similar framework, like Backbone, Ember, Knockout, etc.) is a must-have nowadays if we are talking about rich client applications.
6. Breeze.js
Finally, Breeze provides you with a way to organize / access data from your thick client Web application. Whether you are using Angular, Backbone or Knockout, Breeze will help you manage your data in a way similar to ORM / ActiveRecord concepts.
So, all these components can easily work together, no doubts (sometimes people are talking about MEAN, MEANS, BMEAN stacks, where every letter is a first letter in the name of a framework / component). But ultimately, it's up to you to decide how many of them you should use in your product. As an example of approach, you can start with Mongo / Node base, and then choose necessary frameworks by asking yourself for the each one, whether it simplifies your life (especially, long-term-wise) or complicates it.