# The OpenBB Annual Hackathon The annual OpenBB internal hackathon that happens in December is always a great learning experience. Every year I’m excited to see what the team comes up with. I believe our engineering team is super pragmatic, efficient, and effective. That’s how we managed to have a wide variety of quality products shipped so fast. This pragmatic vision can also be dangerous because we can easily get caught in our bubbles. That’s also why our engineering team is developing a series of initiatives for engineers to engage more with users, share content related to features or development, or even write blog posts. But let me go back to the initial topic; this is a perfect reason to hold the OpenBB hackathon. Why? Because the goal is to leverage our products to either build on top of it, create our research, or overall explore products we hadn’t the opportunity to explore yet — “put yourself in the shoes of the user” instead of focusing only on pure engineering. This has already led us to incredible results - being, once again - a reason for why we ship so fast: if I’m exploring e.g. the [OpenBB Platform](https://openbb.co/products/platform) and I find a bug or a potential improvement I can immediately act on it. Or, on the other hand, if I’m creating my investment research using the [OpenBB Terminal Pro](https://openbb.co/products/pro) and I think something could benefit from a small tweak, I can discuss it with the team right away. If you’ve been following OpenBB, you’re probably aware that in mid-2023 we took a huge leap by changing our attitude towards the [OpenBBTerminal](https://openbb.co/products/terminal) — we stopped developing to only maintain; and instead, we started building the OpenBB Platform **from scratch** (learn more about this process and decision here: [Celebrating the OpenBB Platform v4 Beta](https://openbb.co/blog/celebrating-the-openbb-platform-v4-beta)). # The Project With that being said, what was my project for the 2023 OpenBB Hackathon? Succinctly, I wanted to reconstruct the OpenBB Terminal, the first open-source project we had and the project responsible for the company's inception. ## How? Using the [OpenBB Platform](https://openbb.co/products/platform). The OpenBB Platform, at its genesis, it’s simple, lean, modular, and scalable. Because of that, we can add new functionalities and build on top of it incredibly fast. So the question was: **How can we leverage the OpenBB Platform to power the OpenBB Terminal?** ## Why? - The OpenBB Terminal was the main booster for the creation of OpenBB in the first place. - Even though there haven’t been new functionalities on the OpenBB Terminal for a couple of months now, it still has consistently over 8,000 monthly active users. - If we can leverage the OpenBB Platform (and automate its usage) for powering the Terminal, it will be very low maintenance - since everything else but infrastructure (which hasn’t seen changes in a long time) will be on the Platform side. - It’s an amazing example of how the OpenBB Platform can power a complex application. ## Implementation ### Single command The OpenBB Platform uses [Pydantic](https://docs.pydantic.dev/latest/) to create data models, which then are leveraged so users can consume provider-specific content in a standardized way. This also means that every field of the data model is carefully crafted: good names, good descriptions, and type annotated. The OpenBB Terminal uses [Argparse](https://docs.python.org/3/library/argparse.html) to create the commands that are available for users. If you have used it before, you probably remember that Argparse needs to know the name, description, and type of each argument when creating the program. **But wait**, I see a lot of overlap in those paragraphs! Exactly. The first step to implement this project was converting a Platform’s single command into an Argparse program — the famous “divide to conquer” approach — with the idea that, if we do it for one command, we can then automate it to every other command.

Single command translation diagram — Fig 1: Single command translation architecture diagram.

``` What's the “Argparse Translator”? In practice, it’s a Python class that given any function is capable of generating an Argparse program. ``` How does that look in practice? Using this concept, we can generate an Argparse program in a couple of lines of code.

Fig 2: Using the help command on an Argparse translated Platform command.

Fig 3: Using `obb.equity.price.historical` as a command line program.

And just like that, we’re now using the OpenBB Platform as a command line program. ### Handling menus/routers By now, we could already replace the model and views from the Terminal with the Platform’s commands, by replacing them directly on the controllers, which would improve maintainability a lot since the codebase would be drastically reduced. However, this is not ideal because we would need to adjust the Terminal every time a new command or menu was added to the Platform, and we want this process to be straightforward and **automated**.

``` What's the “Argparse Router Processor”? In practice, it’s a Python class that, given any target class, it’s capable of creating a series of Argparse-translated methods. ``` On the OpenBB Platform, each asset class (cryptocurrencies, stocks, fixed income…) is built on their [router](https://fastapi.tiangolo.com/reference/apirouter/); on the Terminal, those are called menus. If you’re a user of the Terminal, you also know that each menu might have several submenus. And that’s no different on the Platform, where each router might have its sub-routers, which is very good for interpretability since everything is correctly grouped. That also means that our Argparse Router Processor can’t really grab methods from the target class. Instead, it needs to recursively find the sub-routers in order to find all the available commands. When in action, the expectation is that it flattens all the available commands into the `translators` and also keeps track of the hierarchy on the `paths`. Here is an example:

Fig 5: Equity Router being translated to Argparse functions.

### Assembling the pieces With the above, we’re already in a very good spot to automate the creation of Terminal menus leveraging the Platform. We only need to have some other piece of software that can: - get the OpenBB Platform as an app, - discover its routers (that at the end are classes!), - and, with that, create a series of controllers that the current Terminal infrastructure can interpret and render so that we can keep pretty much the current UX.

Here’s a sneak peek at how it may look in the future:

Considerations: - In the video, we’re only showing the equity router being translated. - This hackathon project turned out to be a proposal for the continuity of the OpenBB Terminal, and it’s currently being reviewed by the OpenBB team. - This is not yet an implementation of the OpenBB Terminal. If you’re interested in knowing the implementation details, please refer to [Pull Request #5302 · OpenBB-finance/OpenBBTerminal](https://github.com/OpenBB-finance/OpenBBTerminal/pull/5302) - the bliss of Open Source Software! But why not try it yourself? Explore the OpenBB Platform for free and start your own project today - check out our Documentation here: [OpeBB Platform Documentation](https://my.openbb.co/app/platform/examples). Stay tuned for more news about the future of the OpenBB Terminal. Thanks for reading!

Stories by Henrique Joaquim

Building a command line interface (CLI) using the OpenBB Platform

Meet Henrique Joaquim