I have a bit of an architectural question I hope you fine people could shed some light on. At my company we want to utilize graphql, were on the same page about that. But, there are some folks in our organization who insist on having whats called a backend-end-for frontend (BFF from here on out, you can familiarize yourself here if not familiar: http://samnewman.io/patterns/architectural/bff/) for our individual frontends instead of letting the front ends themselves query the graphql server for what they need. They then want to expose REST endpoints for the frontends, where the bff is this interim layer to the graphql server. So it would look like this: Frontend 1 =====>RESt====>BFF for frontend 1=======>graphql. They want that bff to be a restrictive subset of the entirety of the graphql backend. So , my question to you all is kind of two fold. 1. Is this even reasonable given we can restrict queries via authorization and 2. If I have to deal with this, is it entirely doable to make that BFF a graphql service that has the same schemas they had hoped to expose via rest, and have that use graphql as well to aggregate from the "far backend". Graphql is a godsend for clients, so I would love to use it over still constructing http request for endpoints unnecessarily. Im open to any and all advice, even those indicating that what I would prefer is not as ideal as what they are suggesting.
In my opinion you want to create an API Proxy in front of your REST services. This is a very popular approach, implemented for example at Xing and Github (as far as I know). This would remove the BFF layer at some point, the only reason to keep it alive is to support legacy clients. This is because this GraphQL proxy is a better version of the BFF pattern. This talk from GraphQL Europe might be helpful. You might want to spend more time on learning about GraphQL before diving in. One idea could be to build a prototype in Node.js that uses the backend services to create a GraphQL interface. Depending on the size of your application you might want to implement this in a different language (like Scala + Sangria at Xing).
Related
Im building a chat that uses a api rest full, but i found a problem storage jwt in client side (cookies and his problems), so i opted to use sessions(it's a better option in security terms), that adds state to my app.
I should create a separate server that handles the sessions and also have my rest api?, and apart another server that implements some functionality such as a push server (which I plan to implement). Because I really don't like the idea of having everything on one server, and if so, what should I take into account? (have more than an rest api server and other with his funcionality).
I'm a developer and i think so this require architecture knowledge, and i have no many idea about servers. If you can give me some idea about the topic to get better on it will be great, and what's the better option in this case.
Thanks, give a nice day
I am trying to build a HAPI REST (API) Server. I think I'd like to make a separate NodeJS server for the front end and separate the two entirely. It would be nice that they don't know about each other at all to simplify development (like both having access to the database - but I assume that would allow for collisions and crazy things).
The idea is so I can scale one and not the other, or I can secure them differently (user/pass for front end, api key for back end), or replace one and not the other.
I assume I should have two different servers, how do I do this? I have seen people just make "two instances" listening on different ports, but it is the same code and can't actually be on separate server instances?
Perhaps I am thinking about this wrong. I assume this MUST be common, what is the regular approach?
I think you're on the right track. Have you read this part of the documentation?
There's a github repo that suggests a starting point.
One strategy might be to embed a Jetty server at a custom context path in your Java app and respond to Hapi Fhir queries.
You should be able to then proxy all your requests at the server level for secure things like user auth or open up certain resources to be queried openly from NodeJS or any REST api.
Finding out how to embed a jetty server should be simple. Proxying requests and auth, maybe not so much
I'm building a next.js project and while I usually would just use the "Custom Express Server" method to implement my graphql API (using apollo-server-express), I thought that it might be a good idea if I decoupled the next.js project from the graphql API so that each of the servers are hosted on different machines.
But usually I would implement any session-related logic in the graphql API, using something like graphql-passport; I figured that's good practice because if I ever choose to add another frontend (maybe a mobile app or something) they can share the same session logic. But given that I'm server side rendering content with next.js, how do I forward the user's session info to the graphql server? Because the next.js server shouldn't have to redo authentication, right?
Let me know if there are any flaws in the architecture too, I'm kind of new to this.
Using the Next server to run the GraphQL service is certainly not a good idea, so yes, do separate the two.
Letting the Next server SSR-render pages with user specific content using the users session is probably not a good idea either, unless you have some specific use case that requires the served HTML pages to have the user specific data in them already. The reasons for this are:
SSR rendering will require lots of server side computations since all pages always will have to be rerendered.
NextJS is moving away (since v9.3) from the getInitialPros() way of doing things towards using getStaticProps() to generate a page that is common for all users and which can load its session dependent stuff straight from the GraphQL API once it is displayed on the client device.
This approach will generally have higher performance and scale much better.
Should you really want to go the "SSR with user session data" route you start in the getServerSideProps(context) method, where context.req is the actual request which will have all your session data in it (cookies or headers).
This session data you can then extract from the req and pass on to the GraphQL server requests that require authentication.
I really like the Wolkenkit server but when I looked at the client library it seemed a bit too opinionated and I might be using graphQL -- which I think will work well to wrangle all the read models. In that case, can I just use the server with http? What would be involved with that?
Basically, you can access wolkenkit using HTTP or web sockets directly, without the need to use the JavaScript client SDK. All the client SDK does is wrapping the HTTP respective web socket calls in a convenience API.
The server is built upon tailwind, which is a base module for applications built with CQRS in mind. The best place to start is to have a look at the HTTP server API of tailwind, which is used by wolkenkit. There, one could also add a GraphQL endpoint.
Please note that I am one of the developers of wolkenkit, so please take my answer with a grain of salt.
I've been looking at node.js, REST APIs and WebSockets lately to further my knowledge about backend and frontend web development. Trying to go with best practices I see REST API comes up all the time. Now my problem which I don't seem to understand how to properly solve.
Say for example I'd like to have client / server decoupled and for this I implement a REST API in the backend so that my frontend will access and get data to render. Specific (imaginary) example: lets say I want to build a rental service website. Now I would like to have an endpoint for my frontend to access information about certain products, let's say the number of bikes that have been rented so far. I'd like to be able to show this on my frontend (through the help of the REST API) but I wouldn't like for other people who call this REST API to be able to get the data (because espionage is a serious business and I'd like to keep the evil ones away, yes they can webcrawl but bla bla). So in essence I'd like for the localhost machine to be able to access (part of) the REST API but not anyone else. Things get complicated because I'd also like people to be able to create a user on my website so then I'd like to have other endpoints which can then be accessed without restriction because I'm thinking, what if at some point I'd like to have a mobile app that is integrated with the service. Then it will be unfeasible to restrict all requests to localhost.
How would you architect a secure server / client as this one? Or in your opinion is it not that big of a deal to have the REST API exposed to others (the evil ones)?
The above goes for WebSockets as well. I know REST APIs are all nice and neat but I think the future lies in near-realtime connections and so I'm likewise as interested in WebSockets (through higher level modules of course, Socket.io, SockJS etc.).
There are many solutions to secure your API out there and many of them are opensource. Which one you'll use really depends your detailed needs.
But to get you started I will mention a solution that is very accepted and supported by a large community:
Have a look at JSON Web Token, which are for example explained in this Article.
Basically your client requests an authentication token from the server and then stores it locally to reuse it for every request to your API.
The Server on the other hand may protect your API as needed. That means you may also have a public API that does not expect a token in the HTTP Header.
Tokens may also expire. That is handy if you, for example, will allow a new user for registering on your site for a limited time.
Here is another article that explains things.
Now on to the websocket part of your question. YES, you definetly want to protect your server side sockets as well. So look out for a library that supports authentication. Again, I think there are a number of opensource libraries out there.
To mention one: Primus.
Primus is an abstraction layer for many socket libraries underneath and lets you quickly change the socket provider. But it also has an authentication hook that you can implement.
And guess what.. you can use it to check for a JSON Web Token!
Hope this gets you started.