Beagle is an open source framework of cross-platform development, it is based on the native Server-Driven UI implementation in iOS and Android. You can easily change your application’s layout and DATA changing only the screen code in backend.
The developer declares the backend screens and the expose the endpoints that represent them. These endpoints are called using Beagle to render the screen components on the web or mobile.
Beagle works as a ‘bridge’ between front and backend, it is possible that the design components of your application have a parameter in backend which makes a native application possible.
No, Beagle does not interfere with your project’s architecture.
Beagle has a different goal than React Native and Flutter. Beagle’s purpose is to provide Server Driven UI, i.e. to represent the UI in the backend, send a serialized version of it to the frontend, deserialize it and render it.
Since we need a backend representation of the UI, it becomes agnostic of platform and this is the reason why you can write a single UI definition in the backend and not program the same logic in different languages. Having said that, the frontend components (design system) still have to be implemented once for platform.
React Native and Flutter don’t do server driven UI, their purpose is to create visual components and the behavior only once, but in a traditional fashion. If you don’t need Server Driven UI, you should be looking into them instead of Beagle.
Yes! Unit tests like instrumented test work the same way on Beagle.
Yes! If your application already have the developed components in a design system, you are able to use them on Beagle. You only have to see if these components are defined and then it will be easy to register them on Beagle.
No, the application can use only one Server Driven screen in some app’s flows. You can continue in one server driven flow or return to the native screen normally.
No, your application will continue the same and it can be native even with Beagle on it. You may use Beagle whenever you want.
Depends. All server driven application when requests the server a flow, it needs to be connected in order to receive a response from backend. The server driven flows cannot be solved without a connection. But, your if your application is not 100% server driven, there is a part of it that doesn’t need to get online information, then it will work. The application also can be configured to call other screens in case they are offline.
The way to deal with disconnection cases is to create local declaratives screens to fallback
.
No! All the components used will be defined in your application when the store’s upload happens. Beagle is dynamic when dealing with updates, this happens because the work is in the backend and there isn’t any frontend configuration that is big enough to cause a block on Apple or Google. Beagles wants to minimize the deploys
on the stores.
Not, it’s the quite opposite. We made a renderization benchmark
and Beagle - using Yoga’s Layout mechanism - had a better answer than other native renderization strategies, like Auto Layout (IOS)
and Constraint Layout (Android)
.
No, because Beagle uses a cache mechanism to store adjacent screens and, then, optimize backend’s calls. This means that you don’t need to request again to backend in the user’s click moment.
Beagle’s latest version is:undefined
Yeas! Beagle is an open source development framework, which means that its totally free.
It’s possible to create a BFF in a different language. However, we don’t have ready libs
to help you on this process, so it would be necessary that the developer create a mechanism to respect Beagle’s contracts.
One of the main advantages is that Beagles facilitates the development because of backend’s configuration based on BFF paradigm.
This means that Beagle helps you on changing screen’s layouts
, screen’s flows and app’s navigation. All of this is made from pages declaratively created in your BFF with a components' library defined on your application’s frontend, which helps on interface’s change.
It allows you to:
This avoids a replication on each frontend’s platform that consumes this API. The server applies this business logic and use its results to assemble the API response representing it.
Yes! As a cross-platform framework, Beagle helps you on developing application on these three platforms by using the Server-Driven UI concept, which enables that even a BFF may be used on all of these applications.
You can see more how to create Beagle’s projects with each of these platforms on:
Beagle doesn’t interfere in unitary or instrumented tests, so they can be normally done.
Unitary tests has the goal to gauge the code’s functionality in a minor fraction. The applications' tests that use Beagle are done in the same way as in applications that don’t use our tool. That means Beagle doesn’t interfere in these tests.
Instrumented tests are done in applications using Beagle in the same way as in applications that don’t use our tool.
However, it’s important to reinforce that, usually, a server-driven component may not contain an ID that mostly identifies an instrumented test. Thinking of it, we add a WIDGET
element (that refers a component) and an ID attribute
so it can be possible to programatically identify it.
Beagle’s version follows the semantic versioning standard.
Between platforms, the last number (patch) tends to diverge, as some bugs only occur on a certain platform. So, the following example is normal and expected: having version 1.0.0
in the backend with 1.0.2
in Android, 1.0.0
in iOS, and 1.0.3
in web React.
The documentation only has versions with numbers up to the minor, for example: 1.2
. However, some definitions from previous minor versions may still be present, even if they are not valid anymore. If that’s the case, we will try to inform those definitions specific versions.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.