How to bring the most value to Startups’ stakeholders.
A CRUD App with 11 Lines of Code.
Not another React tutorial, but a Manifesto on Code Reusability.
Ben Horowitz has a great quote about his time at AOL:
“After a few months, it became apparent to both of us (Marc Andreessen) that AOL saw itself as more of a media company than a technology company.”
Following that, Ben and Marc moved to found Loudcloud the first cloud computing business, as detailed in his book The Hard Thing About Hard Things.
Startups are hunted by a specter, it is that of wasted resources, with more than 90% of startups failing during the first two years, the only possible outcome of this is time & wasted resources. We’ve led to believe in myths such as disruptive innovation & failing fast, this, however, has not to be the case. Just imagine the fate of a species with a survivor rate as low, they’ll be doomed pretty quickly.
As with every manifesto, this is a clash between two classes. The inability to communicate effectively between technical and non-technical people brings waste in terms of time and money. Solutions have been proposed, in particular, YCombinator has a great framework to assess a product’s viability: build a product people want, do things that do not scale, talk early and often to your users & make a profit as soon as possible.
This is not enough, the technical problem has not yet been framed less solved. Technology is fragmented, and at the core of the issue to communicate effectively lies the inability to prove different solutions. Because of vague concepts as “estimates”, “technical debt”, “scalability” etc. We’ve lost the possibility to evaluate and assess how best to achieve a product’s goal.
One of the most common requests I’ve received in my career is to build Admin or back-office portals, the amount of effort destined to this side-requirement for me is troublesome. Instead of spending time working on the core aspect of the business, where startups can bring the most value, we end up building interfaces to databases in a particular technology again & again.
The process of building interfaces to databases has come so naturally to me, that I’ve decided to abstract it:
import React from 'react'
import { Model } from 'react-asterix'const App = () => <Model
name = {‘To Do’}
fields = {[{name: ‘name’}, {name: ‘title’}]}
DB = {{
app: process.env.REACT_APP_MONGO_APP,
name: process.env.REACT_APP_MONGO_DB,
collection: process.env.REACT_APP_COLLECTION
}}
/>
Whit less than ten lines of code, we get:
1. A list of all the documents created.
2. A view to create new elements.
3. A detail page of every element.
4. A form to update any document.
5. A delete modal.
The component is part of the React-Asterix library, which also includes a sign-up form ─ yet, another very common request ─ and is built using Atomic Design principles.
Atomic Design
Under this methodology, components are ordered and hierarchized based on their size and dependencies.
It draws inspiration for how things are shaped in nature.
“ith the smallest element being atoms, formed by independent HTML tags as buttons. Atoms together form molecules, in the case of the Model component, a “form group” composed by input and a label is a good example.
Organisms are the third step of the Atomic Design ladder and are composed of molecules, for example, a form that is composed of several form-groups and one or many buttons. The Atomic Design ladder ends up with Templates & Pages, templates could be seen as skeletons for recurrent use cases that can render, while pages are templates with content and minor modifications, ultimately pages are the objects rendered to the user.
Technical Specs
Mongo serves as the DB engine, given its seamless integration when building CRUD applications, this includes serverless integrations, powerful queries, and pipeline aggregators, advanced features such as onChange listeners, and a free tier. Naturally, the intention is to turn this into a DB agnostic library, where developers could supply the transformations to interact with the DB as props. The same agnosticism would be applied to the CSS framework, currently, Bulma & even React (choose your own venom).
Is it production-ready?
Not at all, available props need to be greatly expanded, documentation deployed and proper unit & E2E tests developed. Heck, it doesn’t even have CI/CD pipelines yet!
A number of features can and also need to be implemented to the Model Component, for example, the ability to handle numeric attributes and enums properties using HTML selects, with boolean being a special case of enums. Native support for arrays and nested objects would come on a second step.
Another great feature would be to have off the shelf integration with charts ─ yet another very common request ─. But my greatest ambition is to embed AI into the component.
It is still amuses me, that front-end forms do not feature native auto-complete in them.
Is as if we were at the stone age! With native integration to the DB, and TensorFlowJS maturing it might be possible. To be fair, however, the road to production will invariably come with code scaffolding first.
Next Steps
Before getting to production, I aim to add more components to the library. I’ve always thought that working in parallel is way more effective, thus before optimizing the last bit out of the Model component I prefer building something new altogether, for instance, while the Sign-Up component is missing a lot of features, the CRUD Model component reused a lot of the elements from the Sign-Up form.
To evaluate new components I consider how many alternatives there already exist, how commonly the request is used, and what value would it bring to the library.
Landing Pages
This is also, probably the most common request of all, and while there are good and even great alternatives to build home pages, most of them have also the downside that normally is hard to integrate them to the core of the engineering team. As a result, the technology stack used is different, the data and insights produced fall in other tools, and redirections to the main product occur, finally no standard SEO practice is followed.
Providing great content in a Landing Site leads to more conversions than building an astonishing site.
While tempting, at this point, is still a goal too ambitious to pursue.
Funnels
Funnels are also a very common request, and their scope is limited compared to the landing site. Also, the need for integrating them with the core technology stack is greater, thus excluding most of the very optimized marketing target options in the market. Funnels have a great use case as contact forms, that could act as a bridge to building a landing page component.
Funnels are great candidates for applying minor AI elements: for example change the coloring, messages, options, or steps depending on the time of day and location of the user.
While a great fit, I’ve decided to postpone funnels, which will give me time to improve the style of the library and develop a more tight integration with Serverless backend technologies as hooks. In this regard, when a user would finish the funnel a notification to the websites’ owner will be emitted.
AI powered funnels makes a great use case for segmenting leads and e-commerce applications.
Dashboard
As a third alternative, a model of the data would be defined rendering a standard set of charts would be rendered. From the top of my head I can think of: a pie or doughnut chart for categorical analysis of data, line charts for historical and time-related data, stacked charts for nested or subgrouped data, gauges for averages and numerical metrics and scatter and bubble charts for numerical comparisons across two or more attributes.
This is a great component, but again we can even do better, as it requires building an ETL for loading data, and while innovative it is not unique. Behold next comes the winner:
Social Media Component
I’ve noticed a trend, in how we consume online products: as users we need social feedback, before making decisions!
Even if it is from strangers across the globe, when reading a blog post, buying an item, engaging in business, or dating someone, we prefer some sort of social reassurance that our decision is backed by someone.
Making a standalone component to integrate social feedback into your website is a great use case. Objectively, there are not many good options out there given the relative novelty of this approach.
I envision a component that would allow a user to post text, and later images with a like or dislike molecule in it, users would also be able to make comments and possibly reply to them or tag other users.
I’ve taken around one month to develop each of the previous components, so wait for it is going to be … legendary!
Santiago M,
Software Engineer
