顾名思义，应用程序开发人员喜欢开发应用程序 - 最终，他们对前端和后端的关心很少，而且实际上只想向用户带来价值。我本人是应用程序开发人员，并且与其他应用程序开发人员一样，在选择工具和框架时不断推动我决策的一件事是我也很懒惰。
我的主要目标是能够尽可能少地运送应用程序，而我的宠物peeve是愚蠢的重复性机械任务，每当我需要执行它们时，我都会在内部死去。例如，我不想记住要使自己不一致的事情保持一致，这是一个完全多余的重复任务的常见示例。我想我的商标是，当我遇到挑战时，我将始终寻找自动解决方案的方法。 （就像我曾经在90年代建造的应用程序一样，每天向我的女友发送浪漫的短信 - 克服我自己的浪漫缺点）。
我一直在建立工具和框架，以提高开发人员的生产力，大部分时间我的职业生涯中的大部分时间。这一切都始于2006年，当时我确定了使用低代码生成器创建的现代化应用程序的需求，即C＃.NET。我决定不仅创建一个完全自动化的迁移解决方案，而且更重要的是，创建一个C＃类库，该库可以实现等效的开发速度，以前使用低代码工具使其成为可能。
。这是一个很高的标准，因为习惯于低代码工作的开发人员通常也不喜欢细节或内部主体的位和字节的类型。乐于使用低代码工具的开发人员本质上只是希望编写完成特定任务的代码。能够在需要提供无缝和简单的经验的编码框架中复制这一点，直到现在使用代码。
数百个组织已经使用了萤火虫的移民解决方案，从财富500年和政府到小型软件房屋。今天提供的C＃库仍在使用中，可以使“低代码级别”，高生产的应用程序开发以及代码的灵活性结合使用。
对我来说，有效地将完整应用程序运送到一个简单的库中的能力感觉就像是必须便携式并复制到现代网络的东西。车轮开始转动。
是什么把我们带到这里
像许多其他Web开发人员一样，当Node.js出来时，我对随之而来的后端的承诺感到兴奋，最后我们不必学习两种语言来构建完整的堆栈应用程序。只是语言之间的纯粹心理切换 - 对我来说，它是后端上的C＃，然后在前端上的JavaScript，这总是带来摩擦和上下文开关的损失，甚至可以被认为使我的开发人员工作流感到衰弱。
即使有可能在两端启用JavaScript的可能性node.js，仍然没有多少开发人员选择这样做。所有的最佳实践和学习资源继续推荐使用两种单独的后端和前端方法，以及完全分离工具，库和框架，而对于前端和后端的代码和模式很少。
这个具有自己的语法和逻辑的单独语言的作案操作，创造了需要大量重复的样板，例如代码以从数据库中提取数据（对于每个应用程序实体）实体CRUD作为API的操作，每个实体的四个，五到六个不同的路线，这些路线的方法，并且这些方法都会再次复制和重复数百次，并且每次都会更加复杂。你明白了。
这只是在后端。
现在，在前端您有反向代码，您有代码可以将这些JSON响应带走，并从这些响应中重建对象，以便您能够在前端使用它们。只是试图将数据从数据库获取到用户，但是与此同时，您需要代码来读取数据库，序列化JSON，将其发送到路由上，只是必须在前端进行挑选和查询，只是为了获得它在用户面前。
这是所有机械代码实际上什么都不做的机械代码。最终，所有这些都是可重复的。
等等，还有更多。每个API路由都需要能够获取数据，提供某种服务器端的分页，排序和过滤，删除，插入和更新，所有这些非常通用的操作均由所有开发人员一遍又一遍地重复数百万行代码的时间。
现在让我们谈论从前端到复制后端的担忧。直到几年前，前端和后端充其量是共享类型，但是类型的类型不仅仅是字符串或整数。
Commons的问题，例如：如何将它们从JSON序列化，然后将其序列到JSON？您如何验证它们？如今，前端和后端的验证是完全分开的操作。哪个提出问题为什么？为什么我必须记住（作为一个懒惰的开发人员）必须在前端和后端执行两个单独的验证？
在前端代码和后端代码之间，这种二分法也是一个文化方面，那里需要在开发人员之间进行这种无可挑剔的沟通和一致性，这几乎是不可能的壮举。归根结底，所有这些地方都是摩擦的地方，情况可能会出错，两个完全不同的开发人员维护代码。
输入重新
还记得当我遇到挑战时，我的第一个行动是尝试自动化它吗？我无法实现2018年能够在前端和后端运行相同的代码仍然是不可行的。我开始提出这个想法，看看我是否能真正实现这一目标，提高自己的生产力（也希望也为其他开发人员提高自己的生产力）。这是不断重复的。
重返背景故事
恢复起初是一个附带项目，没有名称，并且具有完全不同的（尽管贵族）的目的。我的妻子在一家食品银行自愿参加，结果，我也自愿参加了向有需要的人分发食品包裹。有一天，当我开车分发包裹时，拿着一张纸，上面放着我发现自己在您不想迷路的地方迷路的地址列表，而且我知道我必须构建他们的应用程序来帮助志愿者有效导航。我知道我可以通过代码向有需要的代码运送食物包裹的过程解决很多摩擦将其固定在一起的碎片。
因此，我为我们在Yehuda的当地食品银行的库存和分发构建了一个应用程序，他们可以用来为志愿者快递生成分销列表，并让快递员能够导航到交货并报告交货。我编写了该应用程序，同时也是框架，这是我在构建Web应用程序时想要拥有的框架。一个将关注从后端数据库一直到前端框架的数据流（无论您选择的框架，无论是角，反应还是vue），这不应该如此） 。
不必在前端每个http呼叫的序列化对象上面描述的整个过程，然后将整个过程从后端倒回JSON'可以使用对象在前端查询，然后将整个过程从前端到后端自动化。我终于有了我梦dream以求的框架，这消除了一遍又一遍地编写所有这些样板，重复的胶带代码。
。随着它的增长和使用，我和同事在框架上工作，投资了扩展和稳定性的能力，改善了经过多次迭代的API，并增加了许多功能。以色列各地的其他食品银行迅速采用了基于该框架的申请，他们经常在包裹交付中遇到类似的挑战。我们的第一年后我们的申请帮助从以色列各地的食品银行分发了17,000个包裹。我们为这一成就感到非常自豪 - 我们开始感到我们的框架可能可以承受规模的考验，但是我们不知道接下来会发生什么。
Covid教会了我们规模和安全性
随后，Covid击中了撞击，锁定唐斯从全世界造成了需要的人。突然，需要向老年人分发食物并猛增。需求从每年的17,000包增加到每天17,000个包裹。然后，该应用程序是免费为市政当局，非政府组织甚至IDF的家园提供的，以实现以色列周围包裹的更好的库存，分配和分配。
一旦IDF采用了该应用程序，它还进行了一系列的安全测试和渗透测试，该测试显着提高了其安全性。后端到前端框架，以及原本应该是一个实验的应用程序，仅在2020年就经受了半百万个包裹分布的规模，此后一直保持相似的数字，并且只是在增长。在Covid期间，从澳大利亚到欧盟，美国和南非，全球多个国家都采用了它，以应对大流行期间的类似需求。
这是重新构建和战斗测试的骨干，所有这些都在每月16美元的Heroku服务器上运行。
一旦大流行就在我们身后，我的共同创造者和我意识到我们学到了很多东西。我们了解该框架很健壮，可以扩展，与安全最佳实践保持一致，并提供了民主化在没有所有已知摩擦的情况下构建完整堆栈应用程序的能力。
我们想与世界分享。
因此，我们开放了框架，以使像我们这样的其他懒惰的开发人员能够投入他们的精力，以编写出色的应用程序，这些应用程序可以为用户带来价值，而不是根据可重复的机械代码，显然可以自动化的机械代码。 并由后端和前端共享。
查看Remult，如果您喜欢，请给它星星。让我们知道您希望接下来看到什么，也可以随时为该项目做出贡献。
在我们的下一篇文章中，我们将在生态系统中进行大量工具，希望通过不同的方法来解决类似的挑战，并解开“恢复位置”的位置，以及它优化的。
。