crud 代码生成
如何为初创企业的利益相关者带来最大的价值。 (How to bring the most value to Startups’ stakeholders.)
Ben Horowitz has a great quote about his time at AOL:
本·霍洛维茨(Ben Horowitz)对他在美国在线的工作有很好的报价：
“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.”
“几个月之后，对我们俩人(马克·安德森(Marc Andreessen)来说，美国在线都将自己视为更多的媒体公司，而不是技术公司。”
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.
此后，Ben和Marc创立了Loudcloud，这是第一家云计算业务，详细内容在他的《 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.
新兴企业会受到幽灵的追捕，这就是资源的浪费，在最初的两年中，超过90％的创业公司倒闭，这唯一的结果就是时间和资源的浪费。 我们已经导致人们相信颠覆性创新和快速失败等神话，但是事实并非如此。 只需想象一个幸存率低的物种的命运，它们就会很快注定失败。
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.
与每个宣言一样，这是两个类之间的冲突。 技术人员和非技术人员之间无法进行有效沟通会浪费时间和金钱。 已经提出了解决方案，特别是，YCombinator具有一个评估产品生存能力的强大框架： 构建人们想要的产品，做不按比例缩放的事情，尽早与用户交流，并尽快获取利润。
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.
我在职业生涯中收到的最常见的请求之一是建立Admin或后台门户，这对我来说是繁琐的工作。 我们不必花时间在创业可以带来最大价值的核心业务上，而是最终一次又一次地建立与特定技术的数据库接口。
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.
不到十行代码，我们得到：1.。 创建的所有文档的列表2。 创建新元素的观点3。 每个元素的详细信息页面4。 用于更新任何文档的表格5。 删除模式。
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.
该组件是React-Asterix库的一部分，该库还包括注册表单(这是另一个非常常见的请求)，并且是使用Atomic Design原理构建的。
原子设计 (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.
“最小的元素是atom ，由独立HTML标签作为按钮组成。 原子一起形成分子 ，就Model组件而言，由输入和标签组成的“ 形式组 ”就是一个很好的例子。
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.
有机体是“原子设计”阶梯的第三步，由分子组成，例如，一种分子形式由多个形式组和一个或多个按钮组成。 Atomic Design阶梯最终以Templates＆Pages结束，可以将模板视为可以呈现的重复使用案例的框架，而页面是具有内容和少量修改的模板，最终页面是呈现给用户的对象。
技术规格 (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).
Mongo用作数据库引擎，因为它在构建CRUD应用程序时实现了无缝集成，其中包括无服务器集成，强大的查询和管道聚合器，高级功能(如onChange侦听器)和免费层。 自然，其目的是将其转变为数据库不可知的库，开发人员可以在其中提供转换以作为道具与数据库交互。 相同的不可知论将被应用于CSS框架，目前，布尔玛甚至是React(选择自己的毒液)。
可以投入生产了吗？ (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!
根本不是，需要大大扩展可用的道具，部署文档并开发适当的单元和E2E测试。 哎呀，它甚至还没有CI / CD管道！
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.
可以并且也需要对模型组件实现许多功能，例如，使用HTML selects处理数字属性和枚举属性的能力，布尔是枚举的一种特殊情况。 第二步将是对数组和嵌套对象的本地支持。
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.
另一个重要功能是可以与图表进行现成集成-这是另一个非常普遍的要求-。 但是我最大的志向是将AI嵌入到组件中。
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.
仿佛我们正处在石器时代！ 随着与数据库的原生集成以及TensorFlowJS的成熟，这是可能的。 公平地讲，然而，生产之路总是要首先使用代码支架。
下一步 (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.
在开始生产之前，我打算将更多组件添加到库中。 我一直认为并行工作会更有效，因此在优化Model组件的最后一点之前，我更喜欢先构建一些新的东西，例如Sign-Up组件缺少许多功能，CRUD模型组件重用了Sign-Up表单中的许多元素。
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.
这也是所有人中最普遍的要求，尽管有很多甚至很好的替代方法来构建主页，但是大多数替代方案也具有通常难以将其集成到工程团队核心的缺点。 结果，所使用的技术堆栈有所不同，产生的数据和见解属于其他工具，并且发生了对主要产品的重定向，最终没有遵循标准的SEO惯例。
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.
渠道是应用次要AI元素的最佳人选：例如，根据一天中的时间和用户的位置更改颜色，消息，选项或步骤。
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.
基于AI的渠道是细分线索和电子商务应用程序的绝佳用例。
仪表板 (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:
这是一个很棒的组件，但是我们甚至可以做得更好，因为它需要构建一个ETL来加载数据，而在创新方面，它并不是唯一的。 看得出来接下来是获胜者：
社交媒体组件 (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
Santiago M，软件工程师
翻译自: https://medium.com/weekly-webtips/a-crud-app-in-11-lines-of-code-669b1a6722e2
crud 代码生成
扫一扫
33
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
