DEV Community: MOXY

Next.js with MOXY

MOXY — Thu, 15 Oct 2020 11:14:40 +0000

Some context

At MOXY we aim for a balance between impact, excellence and pragmatism. This has even brought us the Awwwards Mobile Site of Year prize for our own website, which is evaluated by a Google jury.

https://moxy.studio

To achieve this sort of result, our designers and engineers work together from day 1 to deliver a balanced outcome given the project constraints, be it time or budget. This close collaboration between people with different expertise allows everyone to give input early on, often resulting in better ideas and solutions. We’ve combined this into a process that we call Engineered Design (we might talk about this in a future article).

A clear process is key, but we also needed the right tech foundations, and that’s why I’m writing this article, to talk about our web boilerplate, the challenges it solves, and how that improves Developer Experience, and ultimately the User Experience.

The challenge

There’s a lot of frontend craftsmanship involved in projects of this level, especially on making everything work smoothly while keeping the project maintainable. That’s why we use and love React, one of the most popular libraries to build user interfaces.

But React is just a view layer. Every time we wanted to start a project, we were dedicating a lot of time laying down the foundations. The process was repetitive, error-prone and tedious. That time would be definitively better spent on the actual website implementation.

Our first attempt

To reduce the time it takes to setup a project, we created React with MOXY, an open-source boilerplate that packaged React, React Router and modern JavaScript tooling such as ESLint, Stylelint, Webpack, Babel, PostCSS and Jest. It even had support for server-side rendering, which is very challenging and complex to get it right, but more on that later.

Our engineers would copy this project and would have a barebones website working in minutes.

moxystudio/react-with-moxy
MOXY’s boilerplate to create isomorphic react applications.

Many websites were successfully built with it, but it was hard to keep up with the speed in which these libraries release new versions. The maintenance burden was increasing as months passed by to the point it became unsustainable.

MOXY advocates for open-source and its philosophy. If something can be reused, then we create a package. And if that package is not critical for our business, then we make it open-source.

After three years of existence, MOXY has a vast catalogue of open-source packages, and some of them have millions of downloads each month. We’re also consumers of open-source and we continuously monitor what’s being released in the wild.

One of the open-source projects that caught our attention was Next.js, by Vercel (previously Zeit). We immediately saw its potential, and once it caught up with the features we needed, we ditched React with MOXY for Next.js. It was a humble step to replace a project we created with one made by another company, but I’m glad we did it.

Fun fact: Next.js uses cross-spawn ️❤️, one of MOXY’s most popular open-source projects with ~37.000.000 weekly downloads as of this date 😲.

Next.js matured

Next.js is the React framework that everyone was missing. It has a vast feature set, is well supported and maintained, and has a huge community.

One of its core features is Server-side Rendering (SSR). SSR is a technique that allows you to serve an initial payload with HTML, JavaScript, CSS, and application state. JavaScript running on the client picks up the rendered HTML and resumes its normal operation. This approach has many benefits, but the primary ones are:

Consistent SEO, as the crawlers will see fully rendered pages just like traditional static web pages.
Functional Social Sharing, as we can add social meta tags specific for each page. Social networks will be able to correctly show a preview card for all pages.
Faster First Contentful Paint (FCP), as the browser doesn’t need to wait for JavaScript to display content. This improves the perceived performance, that is, how fast a website seems to visitors.

Another core feature is Static Generation (SG). As opposed to SSR, where the server renders pages on every new request, with SG, pages are rendered at build-time. When a request arrives to the server, the page is already rendered and is sent to the client right away. Pre-rendered pages can also be cached by CDNs to further boost performance. The major disadvantage of SG, however, is when you need to update content. It’s very frustrating to change an article in a CMS and having to wait several minutes for the change to be shown on the live website. And for websites that have hundreds of thousands of pages, it’s just too slow to be viable. Next.js v9.4 introduced Incremental Static Regeneration (ISG) under beta, where static pages are updated behind the scenes as traffic comes in. This technique retains the benefits of SG while solving its shortcomings regarding updates.

But what’s awesome is that Next.js allows us to combine SSR with SG and ISG, allowing pages to be partially static and partially dynamic!

A new boilerplate is born

After embracing Next.js, we decided to create a new boilerplate, Next.js with MOXY, which is also open-source. All the code and libraries that were in our previous boilerplate were removed as they are all being abstracted by Next.js. The maintenance burden was gone and we had more time to dedicate to our clients’ projects.

All websites we make have a base set of features:

Internationalization (i18n): Multi-language support is added from the start, even if the project doesn’t initially require it. Uses React Intl and @moxy/next-intl.
Page transitions: Orchestrates exit and enter transitions between routes, includes support to add customized visual effects to such transitions and restores the scroll position automatically. Powered by @moxy/react-page-swapper and @moxy/next-scroll-behavior.

Page transitions on Audio UX, one of our most recent projects.

Accessibility (a11y): Care for accessibility, by using semantic HTML, and paying attention to keyboard interactions or alternative input and output devices. Automatic checks are in place to enforce good practices on accessibility.
SEO: Any top-level pages will have dedicated metatags which integrate with search engines and social media scrapers.
Analytics: Usage of Google Tag Manager to easily add analytics to the projects, like page views or track interactions. Analytics are only enabled after we have consent from the visitor, to comply with GDPR and similar legislation.
Code linting: Usage of ESLint and Stylelint to ensure code is consistent across the codebase.
Unit testing: Automated tests to validate the correctness and to provide confidence upon code changes, using Jest.
Docker: A Dockerfile to package the website into a Docker image that can run anywhere, on the cloud or on-premises.
Changelog generation: A changelog file adhering to the Conventional Commits specification is automatically generated and kept up to date on each release.
Staging pipeline: A CI/CD pipeline that automatically runs tests and deploys the website to a staging environment, with support for pull requests.
Documentation: A webpage with key documentation, including instructions on how to set it up and how to deploy it.

Documentation for Next.js with MOXY.

We have embedded all these features, and a few more, into our boilerplate. Moreover, we have an optional set of recipes that can be followed to easily add other features. Two examples are recipes to integrate with Contentful and DatoCMS, two of the leading headless CMS on the market.

You may visit the project’s website at https://next-with.moxy.tech. Feel free to use it, give feedback and contribute! 🙏

Next.js with MOXY logo

Wrapping up

With Next.js and Next.js with MOXY, our team has an efficient way to kickstart a project with features that meet our base offering. Recipes can be followed to progressively add other features, such as creating a simple REST API or integrating with a CMS.

The developer experience is consistent across projects that are using it, and our engineers are able to switch projects easier than ever. We’re now able to deliver faster and with a higher degree of polishing, two things highly appreciated by our clients.

Below a quick peek on the most recent projects we’ve built using Next.js with MOXY:

Audio UX — https://auxnyc.com

A full-service audio branding agency specializing in audio logos, UX sound design, automotive sound design, audio for voice experiences, and more.

Dashdash — https://dashdash.com

Do more with your spreadsheets. Build powerful sales and marketing tools. Publish them as web apps. All in one tool, without code.

THU Japan — https://japan.trojan-unicorn.com

THU is a strong community with a powerful bond. THU Japan is a Storytelling Bootcamp event taking place in the city of Kaga, Japan in 2020.

At MOXY, we build websites and applications that our customers can feel proud of, instead of being embarrassed and frustrated. Our Engineered Design process helps our customers have a deeper understanding of their challenges, and provides a clear path for solving them through careful design and implementation.

Looking for help with a project? Tell us a bit more.

Written by André Cruz

Kickoff your application with js-libp2p

MOXY — Thu, 15 Oct 2020 09:11:46 +0000

I want to welcome you to libp2p! This guide will walk you through setting up a fully functional libp2p node, so that you can take control of the spacecraft 🚀 from that point on and build your application.

Background

P2P based systems and applications have been around for several decades now. Such projects have well known challenges and difficulties that need to be addressed regarding their networking layer.

Over the years, new projects have implemented p2p networking primitives again and again. These projects usually had their networking layer tight with the application layer and were not open source. Moreover, some projects did not even reach the application layer development as a consequence of all the networking challenges that needed to be solved before getting into it.

All things considered, during these decades the available projects did not contribute to a rapid growth of the p2p ecosystem. One of the primary goals of libp2p is to fill this gap by enabling application and system developers to focus on their use cases and business logic while relying on a composable networking stack.

What is libp2p?

Libp2p is a composable and modular networking stack, which was designed to be able to become the networking layer of any type of p2p system. Its modular nature is the key to enable such a variety of projects, while also being upgradable for future network requirements.

Understanding where libp2p fits is important to understand how it is designed and how it can be used. Different p2p systems have different needs and requirements, while they might run in different environments and have different hardware capabilities.

Considerations before starting

Before you start with libp2p, it is important to understand what environments you expect your application to run on. Nowadays, you can run JavaScript code in several different environments, some of them with their own particularities.

While the libp2p core codebase aims to work in multiple environments, there are some limitations that are not possible to overcome at the time of writing. As an example, browsers do not support listening for connections via WebSockets, but only to dial known addresses, as they are designed for the traditional client-server model. As a consequence of these limitations, some environments will require to think about a network topology and additional infrastructure as a way to achieve connectivity, as well as to provide a smoother experience to the end user.

Create your libp2p node with js-libp2p

It is usually recommended to start with a base configuration of libp2p and build upon it, specially for new users that are not entirely familiar with every single piece of the libp2p stack. The most important documents to have handy are the API documentation and the Configuration documentation. The former is divided into two main parts, one for creating a libp2p node and one to interact with it, while the latter is focused on configuring each type of libp2p module. The configuration of libp2p is a key part of its structure. Each project should go through what libp2p can offer and select what is important for them. Regardless of how it is configured, its top level API will always be the same.

The first step is to install libp2p in your project with your favourite JavaScript Package Manager. In this guide, we will configure the libp2p node in several stages, as this can make troubleshooting configuration issues much easier.

It is important to specify that the following content is based on libp2p@0.29 as the way libp2p is configured might change in upcoming releases.

Basic setup

With libp2p installed, let’s configure the absolute minimum needed to get your node running. The only modules libp2p requires are a Transport and a Crypto module. Moreover, it is highly recommend that a basic setup should also have a Stream Multiplexer configured. The create options can be checked in the API.md#create.

Transport

Libp2p uses Transports to establish connections between peers over the network. You can configure one Transport, or as many as you like. Supporting more Transports will improve the ability for other nodes on the network to communicate with you.

You should select Transports according to the runtime where your application will run. You can see a list of some of the available Transports. As an example, in a browser environment libp2p-websockets and libp2p-webrtc-star are typically installed.

If you need a transport that is still not available, you can easily create your own transport. The only requirement of a libp2p transport is to be compliant with the transport interface.

Crypto

In a p2p context, encryption is an essential component for the communication on the libp2p network. Every connection is required to be encrypted to ensure security for everyone.

libp2p-noise is the recommended module to use at the moment. Secio is being deprecated but other encryption modules might appear soon.

If you want to use your own connection encryption module, you just need to guarantee that it is compliant with the crypto interface.

Multiplexers

Multiplexers are not required by libp2p, but they are super important for the efficiency of the connections using several protocols that libp2p will run. It allows libp2p to run several of its internal protocols, like Identify, as well as allow your application to easily run any number of protocols over a single connection.

Running libp2p

With a Transport, Crypto and Stream Multiplexer modules specified, you can start your libp2p node. However, you also need to specify its listening addresses, so that your transports can listen for connections from other peers. Otherwise, your node will be a "dial only" peer.

This will work perfectly in a Node.js environment, but it will not be able to start in a browser context. The listen multiaddr /ip4/127.0.0.1/tcp/8000/ws aims to listen for new websocket connections on the local 8000 port. As previously stated, browsers do not support listening for connections. As a result, this type of multiaddr should not be used if your application will run in a browser environment. However, you can still use the websockets transport to dial other peers that can listen for websocket connections.

The described issue is one of the main reasons to have libp2p-webrtc-star transport. The other multiaddr /dns4/wrtc-star1.par.dwebops.pub/tcp/443/wss/p2p-webrtc-star aims to listen on a different machine that can listen for new connections. The star server on wrtc-star1.par.dwebops.pub will listen for new connections and relay them to the appropriate peer. More than listening from connection on behalf of other peers, the star server acts as a peer discovery mechanism and informs the connected peers once a new peer joins. Bear in mind that this is a public available star server and its availability is not guaranteed. You should setup your own for production.

You can check the complete API documentation o understand what you can do with your node from now on.

Customize your js-libp2p node

Now that you can have connectivity with other nodes in the network, it is time to select the modules that you need for your application, as well as to tune the node according to your needs.

There are several other modules that can be added, in order to fulfil the needs of a p2p application. These include Peer Discovery, Pubsub, Content Routing and Peer Routing, among others. Bear in mind that you should only add modules you need.

Peer Discovery

One of the most important characteristics of a typical p2p application is its ability to find other peers in the network. Libp2p provides several discovery protocols. Some of them are also dependent of the runtime of the node, like libp2p-mdns, which will not work in the browser.

You can also provide your configuration for each peer discovery module you provide. It is also important to point out that transports with built in peer discovery capabilities (e.g libp2p-webrtc-star) are automatically added as discovery modules (but can be disabled).

With Peer Discovery modules added, libp2p will handle everything and add the discovered peers to its Peer Store.

Pubsub

Some applications will potentially need a pubsub message service for real-time communication. There are two pubsub routers available, but libp2p-gossipsub is the recommended router to use thanks to its efficiency and security. Once you have a pubsub router in your node, you are able to use the Pubsub API Methods, where the most common methods are subscribe and publish.

Content and Peer Routing

Content routing offers a way to find where content lives in the network, while Peer Routing provides a mechanism to find other peers in the network by making queries using a Peer Routing algorithm. There are currently two implementations for each of these, the DHT (Distributed Hash Table) which provides both content and peer routing, and one delegate router implementation for content routing and one for peer routing. The delegate routers aim to leverage more capable nodes to issue DHT queries on behalf of the requesting peer. It is common to leverage go-ipfs nodes for this purpose.

You can have multiple routers, as well as the DHT at the same time. If that is the case, libp2p will start by trying the DHT. If it is not successful, it will try each router until it succeeds.

It is important pointing out that peers with less capabilities are not recommended to use the DHT.

Create your own protocol

So far, we went through the basics for building a regular p2p app. We may decide which modules to use according to our needs, or even create new ones. But, libp2p also allows the creation of new protocols.

Libp2p is a "modular system of protocols", where custom protocols operate in a similar fashion as a RESTful API. Each protocol has an identifier and an handler. As an example, IPFS uses the ipfs-bitswap protocol on top of libp2p for custom data exchange between peers.

After you have your custom protocol, you just need to hook it into libp2p. The handle will listen for stream messages under the protocol and call the provided handler.

What is next?

Once you have your networking building blocks ready to be used by your app, you can start focusing on it! 🎉 But before going into production, you should setup your own infrastructure. The code examples here use public infrastructure provided by Protocol Labs for experimenting, but they are not meant to be used in production and their availability is not guaranteed. According to your requirements and used modules, you might need to setup webrtc-star servers, delegate routers, or even circuit relay nodes.

There are a few new features expected for the upcoming libp2p releases that will help with some of the pain points covered here regarding connectivity and discoverability. Stay tuned and let’s distribute the web together! ❤️

At MOXY we’ve been contributing to libp2p and also leveraging it to deliver distributed applications, namely Nomios and Discussify, among a few others underway. If you are looking for help with a project that could benefit from p2p capabilities, tell us a bit more.

If you have any question, issue, or even new ideas with libp2p, you are welcome to reach out to me directly on Twitter, create a topic in the libp2p discussion forum or open Github issues in any libp2p repo.

Written by Vasco Santos

React Native with MOXY

MOXY — Wed, 14 Oct 2020 09:50:50 +0000

Background

About one year and a half ago, MOXY began its journey in the domain of mobile apps engineering. Even before that, as professionals that build digital solutions for the web and continuously monitor industry trends, we were conscious the web is not always the most adequate target platform to deliver certain kind of products and experiences. At the time, new business opportunities in the mobile market started to present themselves when some of our clients approached us to develop apps for them. We then realized it was time to realign our strategy and decided to seriously invest in exploring the mobile technology scene and train our team to develop and design apps for handheld devices targeting iOS and Android.

If we were to invest resources in learning how to develop to mobile platforms, we were to do it the way right way.

Above all, our premise was that the commitment towards what our clients entrusted us to build and the quality bar we set upon ourselves would have to remain the same: to deliver impactful experiences, visual appealing and polished apps which make us proud and our clients happy.

As such, the mobile development framework of choice would have to ideally comply with the following criteria:

Cross-platform: share a single code base across iOS and Android so we could ship faster and at a lower cost.
Open-source: as an open-source driven company, the technology would have to be backed and maintained by an experienced and massive developer community.
Maturity & stability: the technology would have already reached a stage where it has become reliable to be used in production without major hassles.
Developer experience: the development and debugging tools would have to be easy and pleasant to use. Using the same tools, libraries and languages we already use daily to develop websites would be a major plus as well.
Native capabilities: unlimited access to the native APIs which enable us to develop more specialized and sophisticated apps.
Native-like performance: reasonable load times and smooth animations and transitions.

Why React Native?

React Native is an open-source cross-platform development framework created by Facebook and it was first released to the public in 2015. Armed with the possibility to build native apps using React, a UI library also created by Facebook, React Native’s popularity among web developers grew quickly, which led to the establishment of a thriving community and the proliferation of countless open-source libraries and learning material. Moreover, in the last five years, besides Facebook, several tech giants such as Uber, Microsoft and Shopify adopted React Native and continue to place their bets on it.

Naturally, it also deserved our attention.

As with everything in technology, our choices are motivated by trade-offs and risk is always involved. We ended up choosing React Native as it ticked the most boxes in our list of goals we set fourth above. The decisive factors behind our decision were:

The dominance of JavaScript from the frontend to the backend in our tech stack.
The long standing usage of React for our web development projects and how much we love it!
The possibility to utilize tools and libraries we were already familiar with such as ESLint, Babel, Jest, Redux and React Intl, to name a few.
Our proficiency in JavaScript and React as a whole.

Cross-platform development frameworks are very complex and none of them is perfect. React Native is no exception, but it continues to evolve with fast release cycles and has been getting better and better in the last couple of years. Furthermore, a major architectural shift, several performance improvements and optimizations are expected to land throughout this year. You can stay tuned by keeping an eye on the official blog for announcements and on the discussions and proposals repository to follow ongoing discussions and upcoming developments. Moreover, if you’re interested in having an outlook of the current state of React Native, feel free to check the article by LogRocket to learn more.

Beyond React Native, we did have a look at other contenders in the cross-platform space for native apps, namely Flutter and NativeScript, but, without disregarding their potential, both did not meet our criteria. Had we chosen to use Flutter, we would have to learn a new programming language, Dart, for core development and we determined such investment was not worth for us, at least for the time being. Spending time to learn, master and keep up with React Native, Android and iOS ecosystems was and still is enough of a challenge of its own. Thus, we put Flutter aside.

NativeScript, on the other hand, could have been a more interesting candidate as native APIs can be accessed from JavaScript seamlessly. Unlike React Native, where we have to write code in three different languages to bridge the JavaScript and the native realms, writing code in one language is a major upside from productivity and maintenance standpoints. Unfortunately, NativeScript lacked React support and still does to this day (only Angular and Vue are supported). React has been our library of choice for quite a while now, in which we heavily invested our team to consolidate its expertise; for this reason alone we discarded NativeScript as well, as it would not be convenient to switch to another stack.

React Native CLI vs. Expo

Upon settling on React Native, our next task, most recently, was to evaluate and assess existing toolkits and frameworks that:

Allowed us to easily kickstart new apps.
Offered APIs and tools out-of-the box to speed up development and delivery.

This was essential as in our first React Native projects we spent a lot of time (and money) over and over again to setup the basics before starting the actual development. We had to put an end to this approach and seek a more efficient and effective solution.

In our hunt, the Expo project caught our eye. Expo is open-source, free and one of the most complete solutions we found as it offers a SDK with dozens of APIs, a CLI which builds production-ready iOS and Android binaries and deploys them to the app stores, and much more. To build apps with Expo, developers have two workflows at their disposal: managed and bare. However, from our experience, all the apps we developed required us to have complete control over the native projects and we anticipate this scenario is not likely to change in the near future, so the managed approach does not work for us. Regardless, it was important for us to understand the several limitations of managed projects and lost benefits in bare projects, the most critical to us being listed below:

The build service provided by the Expo CLI is not yet available to bare projects which, in our opinion, is a huge downside and the biggest. Building and deploying iOS and Android apps automatically to the app stores requires knowledge of how app signing works, native development toolchains and APIs or even third-party tools, such as Fastlane. In managed projects, that process is simplified by hiding away all the complexity involved in the process.
There are many native APIs yet to be supported in the managed workflow.
In the managed workflow, Expo bundles APIs and dependencies we may not even use which leads to an increase of the app binary’s size.
Third-party modules which require native access can only be used in the bare workflow.
If we want to use a push notification service other than Expo’s, it can only be done in the bare workflow.
In the bare workflow, common configurations such as setting up a splash screen or app icons are not so straightforward. It is necessary to perform configurations in the native projects of each platform and use native tooling such Xcode’s Layout Editor, Android’s Image Asset Studio, etc.

One last aspect worth noting about the managed workflow is that each version of the Expo SDK is tightly coupled to a specific React Native version and is subject to a time-based release cycle. This can be problematic for three reasons. First, to ensure compatibility and stability, React Native can’t be updated before Expo itself is and, as a result, we might miss on the latest fixes and new features in between. Second, if we’re tied to a React Native version we might not be able to support the latest Android or iOS major versions if an upgrade is required. Third and last, as each new version of the SDK is released on a quarterly timeframe, we might have to wait a while for bug fixes to be addressed. If there are delays during this process, things might get complicated.

To change things for the better, the Expo team humbly took one step back and has been taking several measures gradually:

Last year, introduced Unimodules which allows us to selectively import modules from the Expo SDKs in any React Native app, be it a bare Expo project or not! This outstanding addition results from a change of direction driven by developer feedback and the long-term commitment made by the Expo team to unify the development experience across both workflows.
Building upon the above, the roadmap for 2020 looks promising as it plans to address many of the pressing pain points we outlined here towards the end of the year.

The ideal workflow for us would be the possibility to enjoy the perks offered by the managed workflow combined with those offered by the bare one. In light of the current situation, as we weighed in the pros and cons, we concluded we wouldn’t gain much from using the bare workflow. We eventually decided to remove Expo from the equation for the time being and spin up a barebones React Native project enhanced with foundational features, popular libraries, tooling and conventions. To that end, we created a skeleton app with React Native’s CLI, which is more or less equivalent to an ejected Expo project but without web support (which we don’t need).

We like to keep our options open and, as such, we’re not shutting the door on Expo permanently. On the contrary, judging by the trajectory the project is being taken, there’s a high likelihood of us embracing it sometime in the future. We’ll be closely monitoring how things roll out in the coming months.

A new boilerplate emerges

As a company that advocates for open-source, our vision was to design a boilerplate that would serve our own needs but, at the same time, could be consumed by the open-source community and leverage its efforts.

Enter React Native with MOXY.

moxystudio/react-native-with-moxy
MOXY's boilerplate to accelerate the setup of new React Native based mobile applications.

Following the rationale and principles behind our boilerplate for web projects, there are a few things included by default but some of them can be easily removed, adapted or even ignored as it is not our intention to lock anyone in. Developers are free to use as little or as much features as they like.

Below you can find the base feature set included:

Internationalization (i18n): Multi-language support is added from the start, even if the project doesn’t initially require it. Powered by React Intl and [@react-native-community/react-native-localize](https://github.com/react-native-community/react-native-localize).
Accessibility (a11y): Automatic checks are in place to enforce good practices and correctness on accessibility.
Code linting: Usage of ESLint to ensure code is consistent across the codebase.
Unit testing: Automated tests to validate correctness and to provide confidence upon code changes with Jest and Native Testing Library.
Streamlined SVG support: Import your SVG files just like any other module and use them as a React component. Powered by [@react-native-community/react-native-svg](https://github.com/react-native-community/react-native-svg) and [react-native-svg-transformer](https://github.com/kristerkari/react-native-svg-transformer).
Sane and scalable directory layout: Guidelines optimized for clear organization and separation of concerns.
Screen navigator: Straightforward, JavaScript-based solution to manage of your app’s routes and screen transitions with React Navigation v5.
Environment variables: Twelve-factor your app’s config with .env files and access your variables from both JavaScript and native realms. Enabled by [react-native-config](https://github.com/luggit/react-native-config).
Splash screen: Provide your user’s a pleasant startup experience by displaying a welcome screen while JavaScript is loading or asynchronous operations run to completion. Powered by [react-native-bootsplash](https://github.com/zoontek/react-native-bootsplash).
Changelog generation: A changelog file adhering to the Conventional Commits specification is automatically generated and kept up to date on each release.
Documentation: A webpage with key documentation, including instructions on how to setup a new app.

Documentation for React Native with MOXY.

We have baked in all these features and best practices into our boilerplate and many more are planned to come. Moreover, we have an optional set of recipes that can be followed to progressively add other features. One of such recipes is a walkthrough on how to integrate Redux, a popular global state manager.

What’s next?

Our endeavor is still in its infancy but there is so much more in store! Here’s a quick peek of what’s on the short-term roadmap:

Error tracking & monitoring: Explore the market of error logging solutions such as BugSnag, Sentry and Firebase Crashlytics and develop integrations for a select few in the form of an abstraction layer to enable us to easily switch between implementations. Unhandled native and JS errors will be reported automatically.
Analytics: Explore the market of solutions to measure and analyze user behaviors by keeping track of custom events, such as Firebase Analytics. We’re planning to integrate one such solution in the boilerplate by default and create a set of instructions on how to configure it.
Handle crashes gracefully: Users are never happy when an app crashes unexpectedly and closes abruptly without any feedback. In order to deliver a more professional experience, we have to intercept native and JS errors and display a proper screen to inform something went wrong.
Update to React Native 0.63: The latest version of React Native has been around for about one month now so it’s time to upgrade from 0.61.
Enable Flipper debugger integration: Flipper is now enabled by default on React Native 0.62 and onwards. React Native Debugger is a great project has been serving us well, but Flipper offers a much superior user interface and developer experience. Furthermore, Flipper is extensible via its plugin API.
iOS and Android versioning strategy: We have been exploring industry practices on how to handle the versioning of Android and iOS apps at scale and how it can be fit together with our Git workflows. Inspired by such practices, we will design and document our approach and employ it in the release management process.
Automatic deployment: Design a CI/CD pipeline in GitHub Actions to test, build and deliver iOS and Android apps to TestFlight and Google Play, respectively. We’re looking into using Fastlane to achieve this. We will provide detailed documentation on how to setup everything.
Add support for Expo’s Unimodules: Thanks to the efforts of the Expo team, we can leverage [react-native-unimodules](https://docs.expo.io/bare/installing-unimodules) infrastructure to cherry-pick SDK modules as we go instead of bringing in the whole thing and seamlessly integrate each one in the boilerplate.

Stay tuned! 💪

Meanwhile, you may visit the project’s website at https://react-native-with.moxy.tech/. Feel free to use it, give feedback and contribute! 🙏

Wrapping up

With React Native with MOXY, our team has an efficient way to kickstart apps that meet our business offerings and clients’ requirements.

Now, the developer experience is consistent across projects and our engineers are able to onboard new or ongoing projects with minimal friction. We’re now able to iterate and ship faster with a higher degree of polishing, two things highly appreciated by our clients.

Check out the most recent app we built with React Native with MOXY:

4service NFC

Enables quick and easy configuration and analysis of Tridonic’s LED drivers.

Looking for help with a project? Tell us a bit more.

Written by André Costa Lima