Here Comes the All-New EPNS-SDK (Monorepo framework)
Hello builders, 👋
EPNS is super excited to officially announce the release of its new EPNS-SDK monorepo structure, an imperative step towards improving the developer experience as well as simplifying the overall process of developing on top of the EPNS protocol to a great extent.
The new SDK framework can, technically, be seen as the union of our multiple front-end and backend SDKs for the different environments (production as well as staging).
While the old SDK required developers to work with a different set of SDKs to perform any specific task, the new monorepo structure combines them into one. This leads to improvement in code consistency, and development speed as well as providing adequate accessibility for developers to read, build or contribute to the protocol.
However, before diving deep into the interesting details of the new EPNS SDK, let’s quickly understand the monorepo structure.
What exactly is a monorepo?
In very simpler terms, monorepo can be understood as a single repository that is capable of storing or hosting all the software code referring to more than one project, library, or service with well-defined relationships.
Why use the monorepo structure?
Leveraging the power of monorepo has been a standard industry practice as this structure is used by some major software firms including Google, Facebook Uber, etc to foster rapid and effective development workflows.
In fact, we ourselves evaluated our previous structure and encountered quite a few issues which made us shift toward the monorepo framework for our SDKs.
Let’s take a brief glance at some of the issues with the older structure and how the new EPNS SDK framework solves them:
- Adequate Accessibility for Developers
- Simplifying developer experience while using our tools and allowing more open source contributions towards the EPNS communication protocol has always been one of our top priorities.
- However, having polyrepos (multiple repositories for prod and staging environments) for using different SDK features has been quite perplexing for developers who were essentially trying to build on top of our SDK features.
- Therefore, with a monorepo structure, we have the capability to combine these multiple codebases into one single repository which allows us to have modular packages which are easily accessible and downloadable by developers.
- Developers can now install the specific packages that they need for their use case without any friction or confusion in dealing with multiple repositories and packages.
2. Code consistency and Setup
- With the older structure, one might have witnessed quite a few instances of redundant efforts for tooling or setup for different repositories for performing a similar task.
- With the new framework, tooling and setup for the monorepo can be done at the very initial step and only once as each package has consistent tooling. This significantly drops the number of redundant steps and speeds up the development procedure.
- Additionally, having one single repo also enforces similar coding standards which not just enhances readability but also helps in maintaining and shaping the overall SDK with adequate quality.
3. Code reusability & DRYness
- The monorepo SDK framework encourages more code reusability and DRYness across the entire code base.UI components, utils, or types can be used across the whole project.
- Moreover, developers can now reuse code between the frontend, backend, or until libraries as well.
Alright, now that we understand the core motivations behind shifting towards a monorepo structure, it's time to get a good understanding of what EPNS SDK is and the imperative features it provides.
Introducing EPNS-SDK
In very simpler terms, EPNS SDK is a growing monorepo of packages that provide solutions for a wide range of development tasks one might come across while building on top of EPNS protocol.
The SDK provides an abstraction layer to integrate EPNS features with your own Frontend as well as Backend very easily.
It is a Javascript-based group of packages that helps developers to:
- Send notifications
- Build EPNS features into their dapps
- Enable Access to Push Nodes APIs
- Render Default Notifications UI, etc
Written in Typescript, this SDK also supports React, React Native, Plain JS, and Node JS-based platforms. Support for more platforms shall be added soon.
The SDK has the following imperative modular packages, as of now, that fulfill the specific needs and requirements of developers.
- @epnsproject/sdk-restapi — Provides access to EPNS backend APIs.
- @epnsproject/sdk-uiweb — Provides React-based components for dapps.
- @epnsproject/sdk-uiembed — Provides vanilla JS sidebar notifications for any dapp.
If you are a Developer, this is your time to BUIDL 👨💻👩💻
With the new EPNS SDK, the development procedure is now superly simplified. Moreover, the SDK now provides a wide range of packages for various use cases and features that you can easily use to build on top of the EPNS protocol.
Let’s quickly take a look at some of the most imperative features and functionalities the SDK provides.
The restapi package is the one that provides quite a few different functionalities.
As of now, the core features of this package can be categorized into 3 different types:
- Sending Notifications
One of the most interesting features of this package is the way it simplifies sending notifications directly from the SDK.
It provides us with different ways a notification can be sent to a user based on the Identity types as well as the different Notification types like broadcast, targetted, subset notifications, etc.
Quite interestingly, it allows us to trigger notifications for different sources of the notifications which are defined by the various Identity types.
Read more about sending gasless notifications using EPNS SDK here
- Fetching User/Channel Details
This package allows you to easily fetch imperative details about a user or channel. For instance, getting the subscribed or spam notifications for a user, fetching channel details, searching for channels using a specific keyword, fetching all the channels a user is subscribed to, and much more.
- Opt-In or Opt-Out
It also allows you to opt-in to our opt-out from any given channel directly using the EPNS SDK.
The uiweb SDK package provides React-based components that you can use for your own dapps.
This package makes it extremely simple for you to render both normal notifications and spam notifications items in EPNS templated format and styling.
With the uiembed SDK package, you shall now be able to embed EPNS notifications directly inside your dapp. Most importantly, you can easily build and integrate this without having to use the other packages and save a lot of development time.
EPNS SDK Starter Kit — The best place to get started with the SDK
Alright. while all the theoretical details about the SDK are fine, the best way to learn more is to start using the SDK right away.
And for that, we already have a starter kit prepared for you.
This SDK starter kit allows you to directly interact with all the different packages and their functionalities. Its core objective is to showcase to developers the different ways they can use or interact with the EPNS SDK packages.
This particular kit is built out using CRA, Typescript. The SDK packages should also work out for React using plain JS.
The URLs for the starter kit documentation as well as GitHub repo are attached below.
An important note
It must be noted that the EPNS SDK uses the CAIP format as of now, in order to provide a chain-agnostic protocol for communication between the dapps or wallets.
CAIP 10 format is a way to identify multichain addresses which is extended from CAIP 2. Any blockchain address becomes namespace + “:” + chain_id + “:” + account_address.
Additionally, although EPNS SDK uses CAIP10 format, it defaults to Ethereum address format.
However, as we expand our boundaries to multiple chains in the future, we shall define our own specifications, if need be.
More details about the above-mentioned note can be found here — @epnsproject/sdk-restapi.
Also, if you’re building something with EPNS at the hackathons right now, check out the repo to get you started:
The industry standards we follow with our SDK
- In order to ensure effectiveness when it comes to managing our monorepo, we use NX. Nx is an effective next-gen build system that allows a holistic development experience as well as the ability to generate consistent code, which is quite imperative.
- We are using conventional-commits to follow semver for npm package versioning. Additionally, we use commitizen to restrict commits and follow conventional commits.
- In order to run and validate pre-commit checks, we use husky.
- We have automated CI/CD processes using semver, GH Actions, independent package versioning policy, and changelog generation.
- In order to run proper tests, the SDK uses Jest, which is a JS Testing framework.
Additional resources to learn and build on top of EPNS SDK:
