How EXACTLY do you implement the Balena Electron Block?

Project help
1

So I’ve been at this for longer than I care to admit and I’m ready to just admit defeat and try and get some help here.

I’m trying to run the sample-app found in the balena electron block and I just have no idea what I’m doing quite frankly. I’ve had several balena apps successfully running but I can’t wrap my head around exactly what a balena block is and what I’m doing wrong.

I’ve looked at balena blocks to try and figure out what the commonality is between them to try and find a pattern for some kind of instruction on how to run the sample app and I’m getting no where.

So rather than try and explain all of the things I’ve tried and utterly failed at to get this to work, instead can you tell me what the exact steps are for running the sample app? Explain it to me like I’m five. I have done a git pull for the entire balenablock electron repo. It’s sitting in my directory on my local machine. I can push to my balena cloud. What do I need to do between these two things? There is some nuance, some minor detail, I’m missing here.

The objective is to run the sample-app, preferably automatically at start up.

2

Hey there @KingstonSteele !

Are you talking about this repo specifically? It would be great to know exactly what your goal is, or what it is you are trying to accomplish. I’m not sure about the sample-app you are refering to.

There are a number of ways to get electron running in a container with Balena. I can give an example of an app I made, using electron and an xserver together: GitHub - nucleardreamer/wsf-ferry-schedule

That is basically a simple electron app, with one window, running to display the app on a machine with an HDMI display.

If you can elaborate a bit more, we can certainly provide a little help!

4

Yes, that’s the repo,

The goal is to move away from developing our electron app on Raspbian and instead move it onto balena. This way we can manage a fleet of prototypes and we can push development changes with ease. We’re spending far too much time managing software updates than we should be. Balena solves this.

So at this moment, I’m trying to run the app found at /sample-app. I’d like a breakdown of what the steps are to do this.

5

Hi @KingstonSteele ,

Sorry it’s been a minute, I have created a repository that has a really basic example of how to get an electron app running on Balena. I have tried to comment as much as possible to explain all the parts of the app that are relevant. The readme is still a work in progress but hopefully this will help overall. Let us know the specific questions you have here, promise to respond quicker this time!

  • Flynn
1 Like
6

Hi, thank you for taking the time to make this. It definitely works. I am curious though, why create two containers and serve using express rather than just a monolithic approach and running everything inside one container? Another question is how does this differ from the balena-block approach? Does Balena-Block do the exact thing we’re doing here in your project/example?

7

The idea here is to give a better explanation of how GUI apps (such as electron) can be run inside containers, and possibly eliminate some confusion. There is no right or wrong way (monolithic or separated) to run your application. But there are definitely some benefits to splitting out the pieces of software to do their jobs independent from each other.

In most linux desktop environments, it’s not always obvious that X11 is actually the server responsible for displaying applications. It is a long running process, and its job is to manage the physical connections (mouse, screen, keyboard, etc) on your machine. You can have many applications connecting to the same X server.

Here are a couple reasons/ideas that might make this more clear:

  • You find this same pattern of separation often when running a database like Postgres or MySQL in it’s own container, rather than mixing it together with your application container. Why treat the X server any differently?

  • Splitting the X server from the application helps in debugging. If the HDMI cable gets yanked from your machine, how are you sure it wasn’t your app crashing vs the X server crashing? When they are separated, you will see logs in a clearer way.

  • Separating the configuration of the screen (resolution, rotation, refresh rate, etc) away from your application means you have tighter control over how it should behave.

  • Dependancies are much clearer when you have multiple containers. You know exactly what you application needs in the Dockerfile, vs what is mixed/shared with the X server. This helps with future-proofing dependencies as well.

  • You can develop your electron app in its own container, and be certain that what you run on your local machine is all that will be included in the application, no confusion with a mixed environment.

To answer your question about ‘blocks’, I will admit that the electron block does a little more than it probably should, and it rolls in the X server inside of itself as well (example of being monolithic vs modular). Our idea is to encapsulate individual pieces of functionality so that they can be dropped into a projects docker-compose file, with minimal configuration. Hence the reason for the xserver block =)

1 Like