Ask HN: Best way to open up an internal API between your two servers

[taw1516]

We are a small startup of 5 people. Between people coming in and out and poor technical decisions, we ended up with two backend: one in Ruby and one in Go. Both are serving public data via a federated GraphQL API. Most of business domain logics are encapsulated in one server. But we have some shared logic that needs to be implemented in both. Instead of duplicating logic, I want to write these shared 'services' in the new backend (Go) and expose an internal API for Ruby to consume. What's the low lift way for a startup to implement something like this? Is it just a simple REST API consumed via JSON with an API key in the header?

[austin-cheney]

If you need to perform real time messaging between two servers use either RPC or WebSockets. These are bidirectional messaging in binary without a round trip or large plain text header. What the data is, where it comes from, or how its generated is completely irrelevant to the transmission.

I have a Node.js app written specifically for this scenario. You can try my app to see if it solves for your use case. It is designed right now to support file system streaming, text messaging, status messaging, and so forth. It can be supported to messaging anything you need. Remote instruction execution will require more effort for security reasons.

https://github.com/prettydiff/share-file-systems

[Jugurtha]

I talked about this a bit here https://news.ycombinator.com/item?id=31855604 and here https://news.ycombinator.com/item?id=25186586, which I'll reproduce for convenience:

>Expose a "REST" API and webhooks and you can have practically as many clients or "integrations" as you want.

>Here are design principles:

>- Anything you can do with point and click, you must be able to do with an API call.

>- It should theoretically be possible to clone your product using its API.

>- Users can be anything (people, systems, your own product). For example, our product is built using a plugin architecture, our subsystems hit our API.

>- Someone interested in an event should get that event and be able to subscribe to it. (Again, users can be people or systems, and that event could be the basis of some downstream actions).

Another one I shared elsewhere: It should be as easy to add functionality as it is to remove it. (functionality is in plugins loaded by a core, added and removed from a config file).

On the plugin architecture:

>One of the best, and first, things we did when starting our machine learning platform was to design it using a plugin architecture. There's a lot of scar tissue and horrible experience through our previous ML products we built for enterprise.

>Namely, it was extremely hard to onboard new developers to work on the product. They had to understand the whole thing in order to contribute.

>Changing something was also hard, since it was intertwined. Adding a feature or removing a feature was hard. Especially given the fact we were not designing to spec, and the domain experts we were building for could not give feedback. That was a constraint outside of our control, so we were building for users we never met based on what we thought would make sense.

>The first commits on our own platform were to establish a plugin architecture. There's a core, and there are plugins. We could add or remove functionality changing a config file. Applications are plugins and onboarding is easy and smooth, since a junior developer can start working on one plugin and then expand their knowledge.

>We're reaping the rewards of that.

These were some of the best decisions I've made.

PS: Have a look at https://jwt.io