Phoenix VS RIG

After some time debating which technologies we should use, we decided to go with Elixir and Phoenix. In short, these tools gave us the productivity, stability, safety, and scalability (the company was planning on opening up the application to the public, with a new API added to the mix, so future performance was a bit of a concern) that seemed appropriate for the company's plans.

For testing purposes we will use our RAG system on a popular open source Elixir package, the Phoenix Framework.

Hey, this guide is meant to be a recreation of the Getting Started with Rails Guide, but for Elixir Phoenix. I very intentionally poach their words for sections when applicable. All true credit goes to the writer of that Rails guide. Thank you for creating such an awesome guide.

> I seem to recall Meta/Facebook engineers on HN having said they have a tool that allows engineers to author SQL or ORM-like queries on the frontend and close to where the data is used, but a compiler or post-processor turns that into an endpoint.

I don't know about on-HackerNews but there's a discussion about their "all of Facebook optimizing compiler" infrastructure from when they did the site redesign in 2020: https://engineering.fb.com/2020/05/08/web/facebook-redesign/...

> perhaps not coincidentally, React introduced "server actions" as a mechanism that is very similar to [the above]

Yep - there's also the Scala framework LiftWeb (https://www.liftweb.net/), the Elixir framework Phoenix (https://www.phoenixframework.org/) and of course the system we're using right now (Arc) that do similar things. Scaling these kinds of UUID-addressed-closures is harder (because the client sessions have to be sticky unless you can serialize closures and send them across the network between servers).

- The game uses iframe and fetches the pages from Wikipedia API. I think the usage of iframe may have a huge impact on performance.

[1]: https://www.phoenixframework.org/

A standard Phoenix app contains a priv/repo/seeds.exs script file, which populates a database when it is run, so that developers can work with a conveniently prepared environment.

There was one in the Phoenix Framework (Elixir) about issuing certificates with an invalid end date: https://github.com/phoenixframework/phoenix/issues/5737

Interestingly, Azure had this bug some years ago too leading to an outage. https://azure.microsoft.com/en-us/blog/summary-of-windows-az...

Official website: https://www.phoenixframework.org/

Since you mention Rails, have you seen https://www.phoenixframework.org/

I would not compare this application with Confluent rest proxy, they don't compete directly. With Confluent's Rest Proxy you basically expose all your kafka internals as a REST API, so I don't think it is well suited to expose it to your clients or front-end. You don't have total control of the REST API on Confluent's REST proxy, they have a fixed interface, on Franz you define all the routes, the parameters each route accepts, the validation of the routes, the kafka topics used and so on. Franz was inspired by [Reactive interaction gateway](https://github.com/Accenture/reactive-interaction-gateway), even though is a small subset of it. RIG was too complex and too bloated for my use case. What I wanted is a simple REST to kafka proxy with a single and portable binary and highly configurable without recompiling any code.