Two months ago my book "The Art of Micro Frontends" was published by Packt. Personally, I had a great time writing the book and working together with the amazing people at Packt, which is why I wanted to share the experience and give a little bit of advice from my point of view.

In short, this is how the book looks like on Amazon.

The Idea

The idea of writing a book about micro frontends was born in mid 2019 when Piral was born out of smapiot's open-source efforts. We've been leading and assisting to micro frontend implementations for a while, and our intention was to put together an (almost) ideal pattern into an open-source framework.

Even though our framework is primarily targeted at client-side rendering our knowledge in the whole space is something that is worth talking about. Over the years, I was fortunate enough to give talks at numerous conferences and publish dozens of articles on the subject.

One of the bigger conference where smapiot as a company was asked to present was O'Reilly's Software Architecture conference in Berlin. Here, we got in touch with some of the people at O'Reilly - discussing various opportunities. Ultimately, it became clear that packaging my knowledge into a book may be a task worth doing.

Finding a Publisher

First approached by O'Reilly, but that was no fit as the expectation already deviated from my vision. Also, I heard that Luca may already be in touch with them, so I was not positive that any proposal would make it through their processes. Why should they publish two books on the same subject?

I was then approached by Manning, but since they already got a (great) book by Michael Geers they have only been interested in something like an online lecture (called "live project"). Here, their idea was to come up with some real life scenario that needs to be implemented by the student. I was actually already convinced that this may be a viable way forward, however, the response to the proposal was then frustrating. Keeping all their requirements in mind they then pretty much went into the opposite direction. For me this was a deal breaker as I value consistency and don't like my time being wasted.

The third party to approach me was Packt. Here, everything went right from the beginning. It was clear that they are highly interested in publishing a book and that they want it to be published by me - and the way I envision it. Once settled that we are on the same page they requested a detailed outline.

My advice on this one is to go with a publisher who you believe understands you and the thing you want to write about. If you are not convinced of their intentions or plans for the book then don't do it. Most likely your book will not make you rich. That's fine. But you should be fine with the book and its contents. The book should provide you something you are happy to talk about, use as a reference, and show around. Don't necessarily go with the best offer regarding money. Go with the offer that reflects your idea the best.

The Time

I've started writing the book in November 2020 and finished around May 2021. All in all I'd not recommend spending less time on it. Especially if you want to fine tune some graphics you'll need more - not less - time for writing a book with 200+ pages (the book has even around 300 pages making it even more time consuming to write).

Outlining the Content

One of the hardest parts about writing a book is finding the correct structure. In the end, this will determine quite a few things - and will actually make the book more accessible to some readers than to others. I did not want to do experiments here. So I've chosen a structure that starts with some general ideas and motivations, before it covers the available patterns in the most practical way. Finally, after the practical part ends I've chosen to include some case studies and high-level information which may be useful to successfully implement micro frontend projects at larger companies.

What surprised my from the publisher was that the process of outlining the book was really detailed. It turns out that this is a lot of work. It was not only about finding the right structure, but also explaining it, writing what is actually covered in quite some detail and then even estimating the amount of pages. Especially the last part is tricky.

How should I estimate the amount of pages if I don't know what examples I'll use or how much space they require? What format is used here? I had to make some assumptions here - like A4 with font size 12pt will be used here for these drafts. I also assumed that things like diagrams and code will take about 20% of the space meaning that every word-only estimate would need a fixed factor of 1.25 to be more realistic.

My advice on this would be: Take your time here. This may be the most important work and it will happen before the actual work, which may be deceiving. Everything you do here will not only follow you for the rest of writing the book, but also for the book itself. There may be future editions of the book, but they will rarely (i.e., never) deviate from the plan you make here. Make it good. Think about it twice and then one more time.

One of the things that bothered me in the whole context was that basic things like terminology have not been determined, yet I was already writing a lot of text assuming a standard vocabulary. One of the most basic things was how to refer to micro frontends.

Micro Frontends and Alternatives

If you start a Google search you'll see some variants on the matter: microfrontends, micro-frontends, and micro frontends. Personally, I am a strong believer in microfrontends. If you write "microservice" you also need to settle on "microfrontend". There is no other way. However, if you are a strong believer in the "first one to mention it wins" philosophy then potentially "micro frontend" is the one - this is the name that was chosen by ThoughtWorks when it appeared on their tech radar.

Naturally, there was an initial discussion about what word to use here. While some favored micro-frontends or micro frontends (mostly due to SEO) I was quite convinced that consistency is key - therefore opting into microfrontends. This was then also the chosen name until... well pretty much the last draft. Then it was changed in a mutual agreement due to better alignment with the community (and better search results on Amazon). Today, I still stay strong on my desire regarding consistency here, but I also feel that "MF" is a good acronym. In the end, it does not matter much - as long as everyone knows what's behind that word.

A much easier discussion was around the title.

Choosing the Title

The title of the book should somewhat not only reflect its contents, but also its ambition. It should draw the attention of potential readers. And it should be minimal and to the point. This is not an easy thing to achieve. It may actually be one of the hardest parts in writing. Together with some editors at Packt we brainstormed this a bit and came up with some suggestions. In the end, we settled for a quite conservative, yet bold statement: "The Art of Micro Frontends" essentially tries to be a complete reference for the subject, while staying practical and down to earth.

My advice on this would be: go with a title you are comfortable with and that would make you happy to have on a book. That the title should (at least up to a certain degree) reflect the contents of the book should be self explanatory here. Don't lie, but still try to sell it (and make you happy).

Conclusion

Overall I had a great experience writing the book. The feedback and suggestions from the Packt team has been great. They are always very welcoming and try to make the best possible product here.

The only regret that I have is that I did not insist on reviewing the last draft in more detail. I'd have wished to still get on or the other smaller fix or improvement in there, but luckily, these are only minor exceptions and overall I am pretty happy with the outcome.