• Their “open” event is not accurate, as it can be trigger by either a BOT or a human
• They know this (and have built their analytics dashboard, knowingly or unknowingly, so that it doesn’t reflect this issue)

On the above screenshot, you can see that 46 emails are being opened within 100 seconds exactly. There were 96 recipients in total, so that’d mean about 50% opened the email right away?
That’s odd, isn’t?

But let’s do more testing:

On this batch, we got even better numbers!
66 recipients, 52 of them opened the email within 40 seconds. 🎉

Our marketing team must be awesome, and our product terrific for such quick enthusiasm!
Well, except the “click” rate is … 1%. Odd, isn’t?

But how does that “open” event works, by the way?

It’s simple. SendGrid adds a “pixel” in the email, basically an image which points to a script. Whenever that script is being downloaded, it means the email has been opened. Simple!
This might not be 100% accurate, but you get the big picture.

👉 SendGrid doesn’t know that you’ve opened the email by actually clicking on it, they only know that it has been opened.

And what else could open our emails? 🤔

Well, you guessed it (probably): SPAM checkers, and any other “AI” that would read the email content (like Gmail, to know whether to store it into your “Promotion” inbox and all of that).

In conclusion, SendGrid cannot make the difference between an email opened by an actual human, or by a bot!

And that would be fine, it they weren’t trying to hide it. (or at least, make it obvious that this information is not 100% accurate!)

Companies use KPIs to run a business, and sometimes, those KPIs are “how many people are reading our newsletter?”. Well, when you make strategic decisions like that based on deceptive information, it can hurt.

Following this analysis, I’ve contacted the “Trust & safety” team at SendGrid with a few advices on how to be more transparent about this fact, and decided to write a public article about it.

I believe companies should put transparency over growth.
Don’t just hide your problems, but fix it instead, or at least tell us about it.

N.B: I bet other “Email delivery providers” have the exact same issue, and are deceptive, too.

P.S: I hope nobody got fired “for doing a bad job” because their email campaign had a 1% clicks out of 80% reads. But, Murphy law, right?

SendGrid is deceptive about “Opened emails” statistic was originally published in Unly.org on Medium, where people are continuing the conversation by highlighting and responding to this story.

But, here are the most typical mistakes made using no-code I noticed, from my relatively small point of view.

1) Bad understanding of database relationships, and how it will affect the business.

Often, makers don’t think too much about how their data co-exist with each other. They’re not aware of how much this will slow them down in the long run, early bad decision with no-code aren’t less costly than with code. Some pay the price of such mistakes years after the fact.

💡 No-code creates technical debt, the same way actual code does.

Some tools, like Airtable, don’t help to make the right calls. Airtable, in particular, is one of the worst database I have ever worked with. While the frontend is just awesome, the backend is just as horrific. It feels like it’s been built by a team of drunk underpaid interns during a summer holidays. Simple things, like relationships, allow for many-to-many relations even when you specify you want a one-to-many relation. No other database does that, and for very good reasons.

💡 This is the issue I’ve seen the most, and it’s very difficult to address, because there is no “right way”. The right way depends on the business state at that time and how it might evolve. Also, it will almost always evolve differently from what you thought back then, as the business matures.

Having someone experienced, who understand how the relationships work with the no-code tools you use (which are very different on how they usually work with code!), will be a game-changer.

Bad database design decisions don’t wait years to bite back, a couple of weeks is enough sometimes to facepalm yourself with the “if I had known” feeling.

2) Choosing the right no-code tool, for the wrong job

This is no different from developers choosing “build the fastest compiler” using Node instead of Rust, because they’re simply “most familiar with Node”.

Tools are only great to use when used for the purpose they were created for.

For example, using Airtable when you need millions of records is a terrible idea that will either kill your business or force you to migrate when you need to focus on scaling.

It’s not because something is possible that it’s a good idea.

💡 When looking for no-code tools, make sure you have your “functional requirements” list prepared, with the “must-have” and “nice-to-have” carefully thought. This will tremendously help you eliminate plenty of candidates early, which will in turn save you a lot of time.

Having a quick talk with expert who knows the ins-and-outs of a specific no-code tool can help you validate/eliminate candidates very quickly!

3) Not spending enough time analysing no-code tools to find “THE good fit”

Often, builders want to build, and build fast. But, as pointed out previously, whatever you build will only be as good as whatever no-code tools you picked for the job. Finding the good fit is crucial. And, because of how difficult it is to understand all the limitations of every tool out there, and taking into considerations that those limitations can change at any time, it is extremely difficult to be 100% sure the tools you picked will do the job now, in 6 months, and in 2 years. No one can know that.

In this aspect, open-source software (OSS) can be much more reliable than company-made tools. Not that it cannot die when you need to scale, but even if it does, it will always give you a way to self-host things while transitioning into a new provider. Company-made tools can die, and die hard, leaving you with no alternative than re-building everything at once using a new stack, which is extremely stressful, and often feels impossible.

💡 The time needed to make such an analysis must not be underestimated.

The last time I had to do that, I spent 3–4 months POCing around with various tools, analysed around 30, tried around 12 and POCed about 6 of them, to finally make a conscious decision as to why we were picking those tools.

Ironically enough, it was the very last tool that I found that fit our business the most, after 3 months of trying and failing. I’m glad I didn’t abandon this quest until I found what I was looking for, but damn that was hard on the morale.

4) Not using any convention, or poor-chosen ones

Bad conventions are even more harmful than no conventions at all. Conventions matter in the long run and save a lot of time, while avoid human mistakes.

Airtable, for instance, has very poor built-in conventions (none at all, actually). They don’t help settings any convention at all, and their “friendly” interface doesn’t help either. People think they’re writing casual text when naming tables and columns, and they aren’t aware of all the issues this might cause. Worse, Airtable encourages this by treating columns names as labels, and doesn’t allow making a difference between the “internal name”, and the “display label”.

Sure, naming your column companyName or nameOfCompany isn’t going to be much of an issue at the beginning, until someone else (or yourself!) have a change of heart and start mixing both naming conventions. From there, you’ll have a hard time finding your columns, and you’ll be more likely to make mistakes when writing automations, and those can have terrible side effects.

💡 In my small company, I am not the only one using Airtable, but all new columns go through my review. My teammates can add more columns as they want, but we usually agree on the naming of the new fields previously, during our “design” phase. When things need to be fast, they do so on their own, but ask me to review their naming.

This might sound silly, but if we hadn’t spent that time on this, we wouldn’t be able to have the same naming convention across our 3 airtable database and more than 2000 columns.

I’m not saying we’ve done it perfectly, though, but we’ve highly reduced the technical debt on this side by doing it this way!

5) Not documenting things, or failing at making it discoverable

Documentation is hard, so hard to write, even harder to make it right, and even harder to make if discoverable and actually useful for the people who need it when they need it!

It’s not for nothing that documentation is so bad for internal products, especially those written with actual code!

💡 As a consultant, I can tell you most of the internal projects, whether they’re built by “experts” or interns lack good documentation. Most of the time, that documentation doesn’t even cover the most basic of things like “what this project is for? what does it do?”.

Documentation for no-code is not different, and, once again, no-code tools don’t always particularly help making things right.

Even when the documentation is there, well written and up-to-date, it’s no-use if the person who needs it cannot find it. It must be discoverable.

💡 This might come as a surprise for many non-developers, but the best documented projects out there often are open-source projects!

Why? Because nobody will give a damn about a project if they don’t understand what’s it for and how to use it! That’s why OSS always have great documentation, because they rarely get famous when they don’t, no matter how good the software is!

Finding the right way to document your projects, one that works for everybody, is a challenge. It takes time, it often feels useless and a waste of time, but it if not done properly, it will slow down your scaling, not on the technical side, but on the human side. You won’t be able to bring in new people efficiently if things aren’t properly documented.

Also, it gets even harder when using multiple no-code tools, like Airtable, Zapier, Integromat, N8n, and having your whole business made of pieces from there and that. It makes things really hard to understand, and having an overview is quite a challenge.

<aside> 💡 We document all our Airtable formulas and automations (Airtable, Zapier, Integromat) into a dedicated GitHub repository. It feels like a waste of time to keep that up-to-date constantly, but it saved us quite a few times, too.

For example, when deleting/renaming a column in Airtable, it’s the only way to easily and quickly know what automations/formulas are affected. A simple “search in project” and we get the whole overview of every affected components. This gives me such a great piece of mind for maintaining things that I can only advise you to do the same, although I wish it was simpler and automated.

There are plenty of other “typical mistakes” with no-code, but this is my curated top 5. Don’t hesitate to share your thoughts and feedbacks!

The 5 no-code most typical mistakes and how to avoid them was originally published in Unly.org on Medium, where people are continuing the conversation by highlighting and responding to this story.

The only thing you must really be careful about is to not have anything under pages that aren't actual pages (e.g: tests, components, etc.), because there is no way to ignore them and Next will bundle and deploy them as actual pages.

You can choose to have your code at the root level (/pages) or under src (/src/pages). We prefer the latter, because it makes it more obvious what is actual app-related code and what isn't.

The usual folder structure

Most people will organize their project using a folder structure such as:

/public
    favicon.ico
/src
    /components
        /elements
            /auth
                AuthForm.tsx
                AuthForm.test.ts
            /[Name]
                [Name].tsx
                [Name].test.ts
    /hooks
    /types
    /utils
    /test
        /api
            authAPI.test.js
            [name]API.test.js
        /pages
            index.test.js

    /pages
        /api
          /authAPI
              authAPI.js
          /[name]API
              [name]API.js
        _app.tsx
        _document.tsx
        index.tsx

This design pattern is very common, and it’s great for small project because it makes it obvious where your files should be located. They’re grouped by “kind of files”. It’s very similar to the MVC design pattern many developers are familiar with.

The main issue with this design pattern is its lack of scalability.

While it’s great at the beginning, and can be a good fit depending on the size of your project, you’ll realize a some point you’d find your files faster if they were grouped together by “module”.

Once you reach 6–10 unrelated features, you’ll wish to have the components files close to the utilities and to the TS type that are specific to your UI components, or even maybe your data model.

Also, you might prefer having all files related to a particular 3rd party within the same folder, as a module. (e.g: Sentry, Amplitude, etc.)

At some point, splitting files based on their kind will not be good enough. That’s where you’ll need modules.

The flexible and “modular” folder structure

Another way to organize things is to introduce modules.
Modules help group together code that is related to each other. They’re not a replacement for what’s common.

Here is how we might convert our previous folder structure to something a bit more modular:

/public
    favicon.ico
/src
    /common
        /components
            /elements
                /[Name]
                    [Name].tsx
                    [Name].test.ts
        /hooks
        /types
        /utils
    /modules
        /auth
            /api
                AuthAPI.js
                AuthAPI.test.js
            /components
                AuthForm.tsx
                AuthForm.test.ts
            auth.js
    /pages
        /api
          /authAPI
              authAPI.js
          /[Name]API
              [Name]API.js
        _app.tsx
        _document.tsx
        index.tsx

We added a new src/modules/ folder where we group all files related to the same feature (here, the authentication as "auth"), instead of splitting the "auth" code everywhere, it is now centralized into a single folder.

You might have noticed the only thing that hasn’t changed is the src/pages/ directory. I'll repeat myself, but you must not have anything there that isn't either a page or an API endpoint.

Everything related to the authentication is now in /src/modules/auth, it's much easier/faster to understand the code being used to authenticate now!

But, you don’t want to always use modules, right? Sometimes you’re writing some kind of utility that doesn’t really fit in any module, something you’ll want to write some code quickly and be done with it.

Modules introduce “thoughts complexity”, because now you have a conscious choice to make about where your file should be. It was easier before to make this decision, because grouping files by kind is effortless, it’s a choice that has an actual answer to it. Moving a component to the hooks folder is wrong, while moving it to the components is correct.

It’s easy to know you did it right. (or wrong)

But, with modules, there is no right/wrong answer! Making it harder to make decisions. Sometimes you won’t know, it won’t be obvious at first (it may never be). Sometimes you’ll figure it out afterwards (“oh, that’s actually a module”).

And because modules aren’t the universal solution to this problem, the key is to allow both.

The common directory should be used for everything that isn't a module, while the modules directory should be used by everything you feel should be a "module".

This way, you get the best of both worlds:

• The ability to quickly add code without thinking much about where it should be (common).
• The ability to organize at your own pace when you feel like that thing has grown too big and all those pieces of code should be brought together (converting from common to modules).
• The ability to quickly find your code in your existing modules and to have an overview of how big a module is.

I’m the author of Next Right Now, a Next.js production-ready boilerplate, and the above folder structure is what we’re using since January 20, 2021. It is the result of feedbacks from the NRN community.

Alongside this new folder structure, Next Right Now has also migrated to “Module path aliases”, which uses absolute paths instead of relative paths for importing modules. (e.g: import ('@/common/hooks/useStuff') instead of import ('../../../common/hooks/useStuff').

If you want to learn more on the topic, read the NRN folder structure documentation!

A 2021 guide about structuring your Next.js project in a flexible and efficient way was originally published in Unly.org on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sometimes, especially on big projects, it becomes this:
import { NRN_DEFAULT_THEME } from '../../common/constants';

But, did you know you can convert to something like this:
import { NRN_DEFAULT_THEME } from '@/common/constants';

This is a “module path alias”, and Next.js has support for those since 9.4 (May, 2020).

The main advantages to module path aliases are:

• Avoids “../” spaghetti code
• Avoid breaking your imports when moving them around (sure, IDE help but when you move a lot of files around, they get confused too)
• Avoid changing the file content when moving the file around, which in turn leads to avoiding Git conflicts! (this is, by far, the main advantage, IMHO)
• You can copy/paste your code, and it’ll work as-it, even if you pasted it into a file on another folder level (and that’s great)
• You can still use relative imports if you want, it’s not a lock-in!
• Do you see more?

So, why not using them? Why don’t we see that more often?

• It requires configuration in several tools (babel, webpack)
• It affects all tools in your project, because all file loaders must be compatible, and configured properly (this is, by far, the main reason why it’s so complicated to get right)

If you use a very simple Next.js project, you can simply change your tsconfig.json to something like this:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/common/*": [
        "src/common/*"
      ],
      "@/components/*": [
        "src/common/components/*"
      ],
      "@/utils/*": [
        "src/common/utils/*"
      ],
      "@/modules/*": [
        "src/modules/*"
      ]
    },

The above mapping is what we’re thinking of using in Next Right Now, but you probably want something specific to your app and way of doing things!

Using a mapping as described above will be enough for Next.js to use import { NRN_DEFAULT_THEME } from '@/common/constants'; properly!

How to convert all relative paths to module paths?

The relative-to-alias NPM module helped us a ton.

It was hard to configure properly because it wasn’t doing anything at first (due to a misconfiguration on our side), but we eventually managed to make it work.

npx relative-to-alias --src 'src' --alias '@/common' --alias-path './src/common' --extensions 'ts,tsx' --language 'typescript'

Running this replaced all relative paths to @/common/.... We eventually wrote a script for this.

This is a quick and easy way to migrate an existing project.

Make sure to commit all changes before running the codemod:module-path-aliases! It'll change lots of files and should be done in a dedicated commit/PR.

Is that it?

Depending on how big your project is, it might… But:

• If you’re using Jest (you probably are)
• If you’re using Cypress
• If you’re using Storybook

Then, you’ll need to configure them, so they understand what @/ means!

And, unfortunately, that’s the most complicated part to figure out by yourself… Because they all use a different way of doing so. They don’t all rely on tsconfig.json, and you don't necessarily only use TypeScript, but JavaScript as well!

Here is an overview of where you’ll need to make changes:

• tsconfig.json
• jest.config.js
• cypress/tsconfig.json
• .storybook/jsconfig.json
• cypress/jsconfig.json
• .storybook/main.js:webpackFinal
• jest.config.js:moduleNameMapper

The jsconfig.json are necessary for WebStorm to resolve the aliases used within .js files. (Otherwise, it compiles but WebStorm displays "Module not found")

Jest has a particular way to understand aliases. Storybook doesn’t have tsconfig.json and it must be configured via their Webpack override.

In conclusion, it can be quite complicated (with a lot of duplicated configuration) to make Module aliases work on a whole project. It takes some time to understand how each 3rd party needs to be configured.

At this time, I don’t have any feedback experience regarding actual usage. This is still under peer-review, and it might take a while until we get familiar with those new paths.

Also, it is concerning how complicated the configuration is. It’s being duplicated in no less than 7 different files! And one might be concerned about what’d happen if it ever breaks.

But, in such event, I guess we can solve it with another codemod that converts all module aliases back to relative paths!

Migrating Next.js (+Jest/Storybook/Cypress) to use module path aliases, instead of relative paths was originally published in Unly.org on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Next Right Now boilerplate recently got an interesting upgrade!

Overview

We’ve added Storybook side-by-side with our Next.js application. It took us about 4 days of intensive work.

We had never used Storybook in the past, and we were looking for a Design System to help our designers and developers build components in a better way, with proper documentation, functional testing, accessibility testing, and interact with our components. Storybook helped us achieve all of that — and even a bit more.

While this work has been done on Next Right Now, any Next.js project can benefit from it.

Check out the Pull Request and documentation to learn more about it.

Check out the result on our Storybook demo.

Main features

• Compatible with TypeScript
• Compatible with Emotion 10/11, useful if you use Emotion yourself, or libs using Emotion
• Next.js router (decorator)
• Compatible with Sentry
• Compatible with node-related libs
• Compatible with CSS Modules
• Static site automatically deployed on Vercel, using GitHub Actions
• Automated tests using Cypress, to make sure you get warned if you accidenly break your static site
• Support for i18next and Locize provider (fetched and cached upon build)

Methodology and learnings

Initial configuration

It wasn’t easy. The most difficult part was Emotion/Node.js, because it required some Webpack/Babel tricks with solutions and workarounds splattered all over the web. Emotion was quite a pain in particular, because their TS types clash between v10 and v11. Next Right Now had been upgraded to v11 last week, but some libraries we use are still using v10, which creates a few inconsistencies, even after configuring Webpack and Babel as recommended.

Definitely not something easy to do. It took us about one and half day of work to get it right. Also, we directly integrated automated deployments (CI/CD) using Vercel and GitHub Actions. That part was easy because we have quite a lot of experience with those already.

Build a solid Storybook foundation

Once all the pieces had been properly configured, we started looking at the Storybook ecosystem. We wasted 2 good hours trying to use knobs before we figured it wasn't the recommended way to do things anymore. (Replaced by controls in v6)

The https://storybook.js.org/addons/ was great to get an overview of all existing addons, and we went through the whole list, to look at all those that were promising. Eventually, we selected 8 officials and 5 community-maintained. Checking all of them took us another day.

// Officials
    "@storybook/addon-a11y": "6.1.14",
    "@storybook/addon-actions": "6.1.14",
    "@storybook/addon-console": "1.2.2",
    "@storybook/addon-essentials": "6.1.14",
    "@storybook/addon-google-analytics": "6.1.14",
    "@storybook/addon-jest": "6.1.14",
    "@storybook/addon-links": "6.1.14",
    "@storybook/addon-storysource": "6.1.14",

    // Community
    "storybook-addon-designs": "5.4.3",
    "storybook-addon-next-router": "2.0.3",
    "storybook-addon-performance": "0.14.0",
    "storybook-css-modules-preset": "1.0.5",
    "storybook-mobile": "0.1.29",

We documented them all in the .storybook/main.js file

Those addons were “must-haves” to us. Eventually, we disabled storysource and we don't actually use performance much yet, but it looks promising.

Storybook has a special essentials package regrouping all the "essential" features, it definitely helped us! (but we're greedy and wanted more!)

Mock our app behavior

And then, we had to mock stuff around, using Decorators, configuring i18n with Locize so our components could behave in Storybook the same way they behave in Next Right Now. Overall, it wasn’t so hard, but took time to get right.

Writing actual component Stories

Once we were done with the configuration part (around 2.5 days in total), it was time to do the actual work: Write stories for ALL our components.

And… it was hard. We had written a few stories during the configuration (of course!) and we knew the basics, but it wasn’t obvious what were the “Best practices” really. Also, looking at stuff on the web didn’t help and was quite confusing, as they were plenty of examples using v4 or v5, and not many using v6 (which is still quite new!).

At some point, we figured how we’d write our components in such a way we’d avoid code duplication (within stories). But it took us much longer than we wished to.

To be honest, we don’t really know if our way is “the” way. It’s one that makes sense, avoids code duplication, is simple to maintain and extend.

Is it good? Definitely.
It is the best? You tell me.

Eventually, we managed to write stories for all our components. It took us about 2.5 days.

Caveats and pains

• Babel/Webpack are real pains. They’re like a double edge sword, either you figure out how to configure stuff or you don’t. If you do, great, you can now work on the real stuff. If you don’t, well, you suck. Or that’s actually what it feels like. Personally, I hate configuring Babel/Webpack, because I’m not familiar with them, and I don’t want to learn them either. They’re too complicated for my taste, and they evolve with breaking changes too often, too. I don’t know why it was so complicated, it just was, and it could have been avoided.
• Storybook documentation is good, but it’s not great yet. We got lost several times about how to write our components, met a few bugs that made us feel dumb (hello .storybook/manager.js with your broken cache), had to go around and around the documentation to find how to configure default stories, override stories, how to disable controls for properties (we eventually wrote a withPropMock HOC for this). TS helps a ton, but there are yet quite a bit of uncovered documentation. They're working on it, and we've seen far worse. Overall, we had a good experience, but it can improve!
• Some stuff that should be simple (like sharing CSS for all stories) was quite complicated and really not developer-friendly.
• We ended up re-writing our stories completely several times, until we found the “right” way.

Final words

Adding Storybook was exciting, a bit needlessly complicated, but the result is great. It’s going to be tremendously helpful for our Product Owner, Designers and Developers to collaborate at Unly, and the team is very excited to benefit from this update once we’ll ship it into our private Next Right Now forks!

Having experienced a bit of Storybook v5 and v6, the v6 provides a much better developer experience, great job to the team, it’s lovely to see OSS building such great products!

Using Storybook 6.1 with Next.js and Emotion 11 — Advanced usage and best practices was originally published in Unly.org on Medium, where people are continuing the conversation by highlighting and responding to this story.

Next Right Now is a production-ready boilerplate for Next.js.

Authored by Unly less than a year ago, it has recently reached 500 GitHub stars, with more than 1000 unique visitors in December 2020 alone!

Our main motivation by releasing our internal framework as open-source software, was to share it with the community, hoping the quality would increase.

And it did! In 2O2O, Next Right Now was visited by people from 139 different countries, for a total of ~6k unique visitors!

Open-source takes time, it really does. But it’s part of our core at Unly, our goal is to help students access higher education, and open-source is naturally on the way!

2020 statistics

Unsurprisingly, most visitors were from the United States.
What was more surprising through, is that India is ranked 2nd!
And France is 3rd, that was also a great surprise considering we’re a French company ourselves!

Chrome was used by 80% of the developers reading the NRN documentation, Safari comes second (10%), then Firefox (6%) and Edge (3%). Nothing astounding here.

Bounce rate was around 50%, which isn’t bad. There were more than 35k page views in total, with an average session duration of 2:36mn.

Those statistics are interesting and show us developers come back and spend even more time on the documentation, which is a great sign for conversion. That means people like what they see, and they come back for more.

And more, we’ve got!

2020 features

There have been some incredible features implemented in 2020, thanks to the community:

• Trigger a GitHub Action workflow remotely (workflow dispatch), we’ve used this to trigger Vercel deployments from our Stacker app and from GitHub Actions UI itself!
• A Vercel deployment webhook was added in December 2020, making it possible to get notified when a Vercel deployment is completed. We’ve used this to update our Airtable dataset automatically, works very great!
• We’ve released our first GitHub Action less than 2 weeks ago (awaits for a Vercel deployment to be completed) and we’re already working on a new one! (share GitHub Action variables between jobs) and it’s being beta-tested at the moment!
• We’ve recently updated the Next Right Now documentation, and explained in-depth all our built-in scripts and built-in utilities, among many other things.
• Automated versioning, using the Git commit history.
• Automated releasing, using GitHub Actions! (we’ve added quite a lot of automations this last month alone!)
• Auto-aliasing of Vercel custom domains, for production but also preview! (which is a paid feature on Vercel, and quite an expensive one, too)

What about 2021?

We have many things planned for 2021, and we’re very excited by the recent Vercel/Next.js announcements. 2021 looks promising already!

Also, we’re gonna start a new big open-source project! It might just become the most flexible Chatbot out there ;)

Next Right Now in 2020 — Most flexible and production-ready boilerplate for Next.js was originally published in Unly.org on Medium, where people are continuing the conversation by highlighting and responding to this story.

Next Right Now — Flexible production-grade boilerplate for building web apps (monorepo), with Next.js, Zeit and TypeScript

Building a web app is hard. Building a production-grade app with a high Developer Experience is even harder. Configuring all must-needed frameworks and libraries is quite a challenge, and takes weeks, if not months of hard work.

Monitoring, analytics, reusable styles (css-in-js), graphql, i18n, testing, end-to-end testing, deployment pipeline (CI/CD), typescript, serverless… All these things are must-haves in 2020, and making them all work together is another challenge.

That’s why we released https://github.com/UnlyEd/next-right-now, a boilerplate to help get started with all that. Though opinionated, it’s flexible enough to adapt to your own needs. The goal is to get started with a production-grade setup in a couple of hours, instead of a couple of weeks (at the very least).

There are so many tools in the JS ecosystem now that one must have an opinion on what’s good-enough and what isn’t. It takes time to compare all css-in-js libraries, and that’s just one tiny choice one must do to build isomorphic/universal web applications nowadays.

Next Right Now will help you get started quickly, and can also be used as a great learning resource, because we’ve documented about everything.

You want to build your own blog? An e-commerce website? Some showcase web app? NRN can help, from development to production.

And, it’s flexible. Because you will not agree with all our opinions, and that’s fine. Just get rid of what you don’t like, as simple as that.

Let us know what you like/dislike!

Next Right Now — Flexible production-grade boilerplate for building web apps (monorepo), with… was originally published in Unly.org on Medium, where people are continuing the conversation by highlighting and responding to this story.

We use Airtable for various things at Unly, and we have always been concerned by the inability to create scheduled backups that really fit our needs. Despite the fact Airtable has its own backups/restore feature, it didn’t fit our needs.

And, because Airtable holds lots of business-sensitive data, it was a very big risk for us not to be in control of the backup&restore process.

So, we built a tool that is designed to perform scheduled backups automatically, and deal with backups lifecycle (auto-removal, etc.). Today, we’re releasing this proprietary software as OSS under MIT license.

UnlyEd/airtable-backups-boilerplate

Because backups are very sensitive things, it didn’t make sense to us to build something where we would hold the backups ourselves. Those are your data, and in this world controlled by GDPR and alike, nobody likes to give such sensitive information to 3rd parties. So, we built a software that runs under your AWS Account, so that you are in control of the whole thing.

We hope the Airtable community will appreciate such effort, as it is a long-required feature and need that has been asked multiple times across this forum alone.

Therefore, configuring this software will require some technical skills (AWS), even though everything has been made to make it as simple as possible. (we hate complexity too)

Regarding pricing, it is very cheap as it relies on AWS Lambda for the server part (serverless), and AWS S3 for storing the backups themselves. Calculating exactly how much it’s gonna cost is complicated, but because of AWS Free Tiers and because both Lambda and S3 are very cheap, it’s most likely not gonna cost you anything as long as you don’t save Go every hours.

We use it internally to make backups of 7 Airtable bases on a daily/weekly basis, cost will be $0 for the year. Obviously, it really depends on how often you backup, and how big are your data.

Let us know what you think about it! :slight_smile:

P.S: Check out https://github.com/unlyEd, we release lots of things as OSS

Unly Releases an Open Source Software for “Airtable Managed backups” was originally published in Unly.org on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ve been working with i18n (internationalization) for a few months, and we couldn’t find any easy way of knowing what’s the user’s language that works both on the browser and on the server.

There are tons of libs out there, but none that are working universally. So, we decided to outsource our proprietary implementation and release it under MIT license.

Also, because we’re fans of the Next.js framework, we’ve made an integration example with a demo available there:
https://universal-language-detector.now.sh/

https://github.com/UnlyEd/universal-language-detector

Did you get stuck too with a similar issue when implementing i18n? How did you sort it out? Does this lib help? Let us know! :)

Universal language detector for JavaScript (browser + nodejs) was originally published in Unly.org on Medium, where people are continuing the conversation by highlighting and responding to this story.

How building our own “Typeform to Google Sheets connector” improved our “non-developer” collaborators productivity

Empowering collaborators to analyze data from Typeform, without involving developers

Typeform is one of the online services we rely on at Unly, but they don’t always provide exactly what we need. For instance, we got stuck with the “export to CSV” feature which isn’t customizable enough to our taste and didn’t fit our needs.

So, we built our own solution by connecting Google Sheet to Typeform API!

Now, fetching Typeform Responses in sheets and keeping those sheets up-to-date is dead simple and can be done by any collaborator, without relying on developers!

The problem

When using the native “Export to CSV” feature through Typeform platform, you can’t customize whether you want the sheet’s header to use the “questions labels”, or the “refs”.

Typeform will export the couple “question: answer”, but doesn’t provide the ability to export “ref: answer”.

This has been an issue for us because some of our forms have coexisting french and english versions, and we need to combine data to cross-analyze and generate statistics. Since question labels are different between versions, it wasn’t possible to cross the data, that’s what refs are for.

Also, refs are useful in many other situations.
Anytime we had to connect Typeform to other tools, we experienced that we needed refs, because they were the only way to uniquely identify a question. In complex forms, we often end up with multiple identical question labels and tools like Data Studio can’t handle that.

Using tools like Zapier has similar limitations, because those limitations come from Typeform itself

The solution

We put this very simple example together so you can experience the complete workflow, from filling the form up to analyzing the results.

Everything starts with a form…

Start with filling the form, to see your responses added to the spreadsheet in real-time: https://fsf-sl.typeform.com/to/mJhgzI

Don’t hesitate to leave out a comment if you’re interested by an open source release of our connector!

Understanding how the Google Sheet works:

Now that you filled the form, you should see your answers in the sheet.

If you want to quickly understand how to configure the sheet, then check out the “Settings” and “API Documentation”. Most of it is explained there!

The Google Sheet data are configured to refresh upon page refresh. There is no auto-refresh configured here, because it doesn’t make sense for this demo.

Check out this tutorial if you want to know more about how the sheet works (auto-refresh, API fetching, etc.), and play around with it

How to consume any JSON API using Google Sheets, and keep it up-to-date automagically

Typeform Ref Editor

If you wonder how we customised our “refs”, check out this tool, that’s what we use!

(until TypeForm releases a proper way of doing so)

Here are a few handy features provided by our connector

• No limit of responses fetched: Typeform API allows only 1000 responses to be fetched at once, but there is no such limit when using our connector!
• CSV-friendly: Typeform API isn’t CSV friendly, but our connector is! The outputData can be customised to fetch data as csv (for Google Sheet usage), or raw (for other usages), or both (for debug, usually).
• Unique “value” key: Typeform API use many different keys for storing the value, based on the type of the data, we only use one, which is much simpler to use!
• Authentication: Each form is secured by its own token. The goal is to avoid granting access to all forms from your TypeForm account at once. It is safer.
• Cloud provider agnostic: Written using the Serverless Framework, we use it on AWS but there isn’t much work to do to make it compatible with any other Cloud Provider. Very simple to deploy, if you’d like to deploy your own version on your own infrastructure. (once open-sourced)

Technically, our connector is nothing more than an AWS Lambda function that acts as a proxy between Google Sheets and Typeform API.

Pricing

Since it’s hosted on a Lambda, it really costs nothing due to the “pay for what you use” design (AKA “on-demand”).

For instance, considering 5 API call every 5 minutes (auto-refresh), we expect around 50k Lambda invocation over a month, which makes it a bill of… $0!

Limitations

• Timeout: The API request can’t run for more than 30 seconds due to AWS API Gateway timeout limit. It’s not really an issue (we experienced about 6 seconds latency when fetching around 1000 responses), but that’s something to be aware of when fetching forms with a many responses (> 10k).
• Google Sheets itself also has its own limit.

We hope you enjoyed this quick demo! Please let us know if you’d be interested in an open source release!

P.S: We may soon implement a way to merge responses from multiple forms together, when exporting them (use case: grouping responses from different forms sharing common refs together, when using localised forms for instance!)
Would that interest you as well? Let us know!

How building our own “Typeform to Google Sheets connector” improved our productivity was originally published in Unly.org on Medium, where people are continuing the conversation by highlighting and responding to this story.