|
|
|
|
|
by markelliot
2772 days ago
|
|
Our systems look more wide than deep, and the breadth happens both in FE and in BE, so our diverse FE apps communicate with a relatively diverse set of BE services — we’d like those interactions to look unified no matter where you hit the system. In other words: we have a large number of microservices without a consolidating middleware. Compared to other frameworks, Conjure more easily retrofits into HTTP/JSON service boundaries (no surprise based on its origins) and, IMO, provides great ergonomics for mixed FE/BE teams, especially where FEs are big and complex with lots of BE interaction. In terms of audience, we’d hope this helps FE/BE teams with easy to use and ergonomic API defs, and think, as above, it’d especially help others who have existing surface area to convert to declarative APIs, even if only as a stepping stone. On the BE/BE comms point: we use Conjure for all RPCs in our systems — while JSON is obviously not as compact as Protobuf or Thrift we’ve found serialization and transmission are rarely bottlenecks, and that, instead, a unified format and common treatment for clients is a boon for operability and stability — and often times also for aggregate system performance. |
|