I currently working on a pet project where I intend to learn a "simple" microservice architecture, meaning no universal rendering (or I thought it ...
For further actions, you may consider blocking this person and/or reporting abuse
I could be on the wrong track here, but employing a microservices-based architecture without a proper API gateway is considered a bad practice. The idea is similar to a reverse proxy of course (Nginx, HAProxy etc): a single interface (facade) sitting in front of all the individual services that makes life easier for clients since then they would just have to talk to one server.
Clients should not have to talk to the microservices directly, for a number of reasons:
It is absolutely crucial that your clients and the microservices remain independently deployable, maintainable, scalable etc.
Of course, for different kinds of clients you could have different gateways like, famously, Netflix does.
The API gateway itself can and should handle limited business logic like combining responses from multiple services and returning them to the user or even authorization.
This might be a good place to start.
In the last few days I checked some API gateways and dumped it down to these solutions:
getkong.org
tyk.io
krakend.io
traefik.io
Traefik seems a nice little project, but doesn't feature any authorization service and the biggest minus is cannot be extended with plugins (to have some kind of auth), but there is a PR request regarding this, based on Go's newest Plugin library: github.com/containous/traefik/issu...
Kong, Tyk, and KrakenD seems nice projects, they are also extensible with plugins.
Looks like these projects also managing load balancing and rate limiting, so using HAProxy is obsolute?
Largely subjective. You might even try developing your own gateway, nothing wrong with that.
I'd prefer using load-balancing, rate-limiting features if they ship with the gateway. Though consider caching as well.
Else, an Nginx/HAProxy instance could be placed in front of multiple instances of the gateway. Best of luck!
Very interesting!
Although I didn't classify what @djviolin wrote as a microservice but I might be wrong :-) I don't know if now "API server" as become a synonym for microservice.
Thanks for the link, I'll check it out!
Gateway wise I always wanted to check out Kong but I still haven't found a project to use it for.
I'll try to answer with what I know:
CORS
Yeah, you definitely need CORS while you're developing a SPA with a different server.
It also enables other clients to consume your API.
Proxying requests
The proxying issue hit me as well, I didn't actually solve it because it was configured in the webpack vue template. If you are using it the solution is here: github.com/vuejs-templates/webpack... - If you are not refer to webpack's own documentation: webpack.js.org/configuration/dev-s...
Authentication
I still have to implement it in my own SPA, because it's not exposed to the web and I'm waiting for some business requirements on how to best do it so I don't have an answer for you. In the meantime I can refer you to some articles (I haven't read everything yet :D):
Thank You!
Yeah, I know about the proxy in
vue-cli, but the problem I don't want to use this Node.js server in production, so I build the vue project and Go will be the static fileserver. For development, the webpack based proxy server invue-cliis fine though.I can implement a proxy in Go which is exposing the api server within the static server (under a route like
/api/v1, this way I can use relative urls inaxios), but my problem with this approach is that the static server is not only serving the static files in this case, it's doing a little bit of backend work also. Which I try to ignore, because what if the static files hosted on AWS?Why don't you just deploy the build of the SPA to the go server so it can serve it?
I'm not using Node as a server, just for development. I have a post build command that builds the static files so that the Python server can send them to the client.