The Garage Architecture

After a couple of weeks break, we’re back to our architecture series. This time, we’ll look at something I’ve recently come up with – the Garage Architecture!

Background

I’ve been recently working on a pet project at home, playing with the all-cool Ionic 2 framework, and I came to a point where I wanted to create some sort of back-end for my app. For some reason, the mere thought of building a full-blown layered/hexagonal application made me feel bad. I was heavily thinking about using the DB directly with PouchDB or using a “backendless” solution like Firebase. To cut the storytelling before everyone leaves, I wondered why, as a “true” back-end developer, I even look towards those “fake” solutions and why I feel some sort of disgust for doing the work myself. My conclusion: pet projects require a different approach than enterprise ones!

Theory of Pet Projects

Dev #1: I have a ton of million dollar ideas. If only I sat down and took the time to develop them… I’d be so rich!

Dev #2: Yeah, me too!

Dev #3: And all the thousands of other software developers around the world. Don’t bother starting, the excitement will stop soon and you won’t finish it anyway.

The quote above is part of a real conversation I once had in a corporate kitchen. I honestly don’t remember if I said any of those lines or I was just listening, but it stuck in my mind because it seemed so true. Every single project I have ever started at home sooner or later ended up dead with an excuse of it wouldn’t work out anyway, the idea was too bad.

If you’re like me, stuck in the continuous process of starting and giving up, or you’re like thousands of others who don’t even start and keep waiting for the fantastic, glorious idea that will excite the world and bring you billions of dollars, let me tell you two extremely important things:

1. The brilliant idea will never come because it doesn’t exist.
2. What counts instead is the EXECUTION.

Anything that was ever created in this world was either a copy, a minor improvement, or a new combination of what have already existed. Pick any successful computer application ever built and with enough research, you will come to the conclusion that they didn’t invent anything new, they just improved an existing idea or simply executed it better. Were there no operating systems before MS-DOS? Were there no video players before YouTube? Were there no social apps before Facebook? You get the point.

Principles of Garage Architecture

Now that you understand my background and thoughts about pet projects, you will have an easier time understanding my point of view. I want to maximize the chance that once somebody comes up with a pet project idea, they actually finish the project and the final output is good enough to make it a success (and they later tell stories how they created a million-dollar product in their garage). Based on all of the above, all my knowledge, and my pet project (failure) experience, I came up with the following five principles:

1. Garage Architecture has to be fun. It has to feel like you’re doing your hobby rather than working extra hours each week.
2. It has to help you produce results as fast as possible so that you get encouraged by the progress rather than discouraged by the lack of it.
3. It has to be cutting-edge in a way that lets you bring the best possible experience to potential customers.
4. It has to be educational so that even if the project fails, you can say, "At least I learned something!"
5. It has to be throw-away-able. If your project becomes a rapid success, you will surely see how many things you did not account for. Don’t get emotionally attached to it and don’t let the code be too attached to itself.

My Garage Architecture

It should be obvious now that Garage Architecture is more of an idea than any particular solution. The actual implementation will depend on the programming languages and architectures (including technologies) you know, use at work, and want to learn in the near future. More generally speaking, it will depend on YOU. Now, I ain’t a mind reader, and this blog serves relatively static content, so I won’t be able to tell you how your Garage Architecture should look. But I can tell you a bit about how mine looks like. Here we go.

Front-End: Ionic 2

As I’ve told you in the Background section, I was playing with Ionic 2, which is basically Angular 2 on steroids, helping it look good on all kinds of devices without much developer intervention. Since I’m a full-time back-end developer at Zooplus and my blog is mostly about Java, I obviously don’t have the skills and time to build nice-looking applications for each device myself. Hence, Ionic 2 seemed like a good compromise.

Working with it is pleasant. It allows me to build web and mobile applications at the same time, and the app’s experience is close enough to native, at least for a beginner like me. That covers the principles of fun, fast results, and cutting-edge. As I mentioned, I’m not really skilled in this stuff, so I’m learning a lot, hence the principle of education is also on my side. To cover the principle of throw-away-ability, I decided to build the back-end myself, so that I’m not limited in any way when replacing front-end clients, e.g. with native mobile applications or when I'm willing to switch databases.

Back-End: Vert.x

I chose Vert.x for the back-end, as I’ve already started learning the framework and had some fun with it when writing the post about Reactive Clean Architecture. But this time, as opposed to the stuff in the linked article, I will be writing the thinnest, most direct code possible. No interfaces, no working around frameworks, no extraneous layers of abstraction. There will be two conceptual layers: endpoints and entities. The former should cover all the non-domain behavior of an endpoint, while the latter would contain domain rules. I haven’t implemented too much yet, so I don’t know if the “repositories” will be needed. Even if so, I won’t call them repositories. I want the system as de-enterprised as possible so that it does not remind me of work in any way.

Maybe one day I’ll share a bigger example of my Garage Architecture implementation, but so far, I have only done a simple PoC analogous to the example in Reactive Clean Architecture. It takes a list of activities and displays it, but this time in JSON format, consumable by my Ionic 2 application. The directory structure looks like this:

The only interesting class in this project is ListActivities. It makes a dedicated SQL query that produces a result ready to be returned as a JSON response from the service. In the PoC, it uses callbacks, but I will probably switch to RxJava in the actual project.

public class ListActivities implements Handler<RoutingContext> {
    private JDBCClient jdbc;
    @Inject
    public ListActivities(JDBCClient jdbc) {
        this.jdbc = jdbc;
    }
    @Override
    public void handle(RoutingContext ctx) {
        getConnection(connection -> connection.query("SELECT name FROM Activities", asyncRs -> {
            if (asyncRs.succeeded()) {
                JsonObject result = new JsonObject();
                result.put("activities", asyncRs.result().getRows());
                ctx.response().end(result.encodePrettily());
            } else {
                ctx.fail(asyncRs.cause());
            }
        }), ctx::fail);
    }
    private void getConnection(Consumer<SQLConnection> sqlConnectionConsumer, Consumer<Throwable> onFailure) {
        jdbc.getConnection(asyncConn -> {
            if (asyncConn.succeeded()) {
                SQLConnection connection = asyncConn.result();
                sqlConnectionConsumer.accept(connection);
                connection.close();
            } else {
                onFailure.accept(asyncConn.cause());
            }
        });
    }
}

Consciously avoiding the layering and de-enterprising my architecture makes me feel like a little home hacker again (fun). By making the code as direct and straightforward as possible, I hope to develop things way faster than I’d normally would (fast results). Playing with reactive technologies like Vert.x and (hopefully) RxJava, it is educational and cutting-edge at the same time. Once the project grows, I’ll try to split things into microservices so that it doesn’t bite me in case I have to rewrite some functionality to something more flexible or more testable. And I obviously won’t get attached to this non-Tidy code, so I’ll be more than happy to rewrite it bit by bit once the pet project becomes a viable product (throw-away-ability).

Your Garage Architecture

Enough talking about me. Now it’s your turn! Take your pet project ideas out of your brain, notebook, or wherever you keep them and start working. Identify what makes you most annoyed in your daily work and do exactly the opposite. Don’t be afraid of doing something dirty (in the programming sense!). Find out some cutting-edge technologies that will allow you to quickly produce a lot of value and learn some new things at the same time. And start producing the code, making it good enough for a valuable product but not perfected enough to get too attached. Let’s finish with a paraphrase of the old WoW commercial slogan: What’s Your Garage Architecture?