Hírek, események

The latest major version of Node.js has just released with a few new interesting experimental features and a lot of fixes and optimization. You can find our highlights from the release notes.

Built-in WebSocket client

A browser-compatible WebSocket implementation has been added to Node.js with this new release as an experimental feature. You can give it a go using the --experimental-websocket flag. The current implementation allows for opening and closing of websocket connections and sending data. There are four events available for use: open, close, message and error – so the basics are covered. It’s pretty exciting to see an out-of-the-box websocket implementation coming to Node, it could spare us the inclusion of yet another library in projects that need bidirectional communication. Be sure to give it a go and give your feedback to the developers!

A flush option for the writeFile type filesystem functions

Up until now, it was possible for data to not be flushed immediately to permanent storage when a write operation completed successfully, allowing read operations to get stale data. In response, a flush option has been added to the fs module file writing functions that, when enabled, forces data to be flushed at the end of a successful write operation using sync. This feature is not enabled by default, so make sure to include { flush: true } in the options if you’d like to use it.

Here is the list of functions the flush option has been added to:

• filehandle.createWriteStream
• fsPromises.writeFile
• fs.createWriteStream
• fs.writeFile
• fs.writeFileSync

Addition of a global navigator Object

This new release also introduces a global navigator object to take steps towards enhancing web interoperability. We can now access hardware concurrency information through navigator.hardwareConcurrency, the only currently implemented method on the object. While this might not seem like a huge change for now, we can assume more and more functionality will be implemented with time, until we have the whole suit of information window.navigator provides in browser environments. This would spare us having to decide between using process and navigator in our code that is to be ran in both a browser and in Node.js.

Array grouping

There is a new static method added to Object and Map, groupBy(), that groups the items of a given iterable according to a provided callback function. The object returned contains a property for each group, whose value is an array with the items that belong to the group. In case of Object, the keys of the returned object will be strings, while the version on Map can have any kind of key.

Additional changes

• Both the fetch and the webstreams modules are now marked as stable after receiving a few changes with this version.
• A host of performance improvements as usual with any new release.
• WebAssembly gets extended const expressions
• Another new experimental flag, --experimental-default-type, has been added that allows setting the default module type to ESM
• The globalPreload hook has been removed, it’s functionality replaced by register and initialize
• Glob patterns are now supported in the test runner

Don’t forget that Node.js 16 is at its end of life, so if you’re still using this version, you should plan to upgrade soon to one of the newer LTS versions as soon as possible! The currently active LTS releases are 18 and 20, with version 22 – that is also an LTS version – scheduled to release in April 2024. You can find more information about the release schedule here.

There are a lot of different JavaScript frameworks out there, and it can be tough to keep track of them all. In this article, we’ll focus on the most popular ones, and explore why they’re either loved or disliked by developers.

React

React is a JavaScript library for building user interfaces. It is maintained by Facebook and a community of individual developers and companies. React can be used as a base in the development of single-page or mobile applications. However, React is only concerned with rendering data to the DOM, and so creating React apps usually requires the use of additional libraries for state management, routing, and interaction with an API. React is also used for building reusable UI components. In that sense, it works much like a JavaScript framework such as Angular or Vue. However, React components are typically written in a declarative manner rather than using imperative code, making them easier to read and debug. Because of this, many developers prefer to use React for building UI components even if they are not using it as their entire front-end framework.

Advantages: 

• React is fast and efficient because it uses a virtual DOM rather than manipulating the real DOM.
• React is easy to learn because of its declarative syntax and clear documentation.
• React components are reusable, making code maintenance easier.

Disadvantages: 

• React has a large learning curve because it is a complex JavaScript library.
• React is not a full-fledged framework, and so it requires the use of additional libraries for many tasks.

Next.js

Next.js is a javascript library that enables server-side rendering for React applications. This means that next.js can render your React application on the server before sending it to the client. This has several benefits. First, it allows you to pre-render components so that they are already available on the client when the user requests them. Second, it enables better SEO for your React application by allowing crawlers to index your content more easily. Finally, it can improve performance by reducing the amount of work that the client has to do in order to render the page.

Here’s why developers like Next.js: 

• Next.js makes it easy to get started with server-side rendering without having to do any configuration.
• Next.js automatically code splits your application so that each page is only loaded when it is requested, which can improve performance.

Disadvantages:

• If you’re not careful, next.js can make your application codebase more complex and harder to maintain.
• Some developers find the built-in features of next.js to be opinionated and inflexible.

Vue.js

Vue.js is an open-source JavaScript framework for building user interfaces and single-page applications. Unlike other frameworks such as React and Angular, Vue.js is designed to be lightweight and easy to use. The Vue.js library can be used in conjunction with other libraries and frameworks, or can be used as a standalone tool for creating front-end web applications. One of the key features of Vue.js is its two-way data binding, which automatically updates the view when the model changes, and vice versa. This makes it an ideal choice for building dynamic user interfaces. In addition, Vue.js comes with a number of built-in features such as a templating system, a reactivity system, and an event bus. These features make it possible to create sophisticated applications without having to rely on third-party libraries. As a result, Vue.js has become one of the most popular JavaScript frameworks in recent years.

Advantages: 

• Vue.js is easy to learn due to its small size and clear documentation.
• Vue.js components are reusable, which makes code maintenance easier.
• Vue.js applications are very fast due to the virtual DOM and async component loading.

Disadvantages: 

• While Vue.js is easy to learn, it has a large learning curve if you want to master all its features.
• Vue.js does not have as many libraries and tools available as some of the other frameworks.

Angular

Angular is a JavaScript framework for building web applications and apps in JavaScript, html, and Typescript. Angular is created and maintained by Google. Angular provides two-way data binding, so that changes to the model are automatically propagated to the view. It also provides a declarative syntax that makes it easy to build dynamic UIs. Finally, Angular provides a number of useful built-in services, such as HTTP request handling, and support for routing and templates.

Advantages: 

• Angular has a large community and many libraries and tools available.
• Angular is easy to learn due to its well-organized documentation and clear syntax.

Disadvantages: 

• While Angular is easy to learn, it has a large learning curve if you want to master all its features.
• Angular is not as lightweight as some of the other frameworks.

Svelte

In a nutshell, Svelte is a JavaScript framework similar to React, Vue, or Angular. However, where those frameworks use virtual DOM (Document Object Model) diffing to figure out what changed between views, Svelte uses a technique called DOM diffing. This means that it only updates the parts of the DOM that have changed, making for a more efficient rendering process. In addition, Svelte also includes some built-in optimizations that other frameworks do not, such as automatically batching DOM updates and code-splitting. These features make Svelte a good choice for high-performance applications.

Advantages: 

• Svelte has built-in optimizations that other frameworks do not, such as code-splitting.
• Svelte is easy to learn due to its clear syntax and well-organized documentation.

Disadvantages: 

• While Svelte is easy to learn, it has a large learning curve if you want to master all its features.
• Svelte does not have as many libraries and tools available as some of the other frameworks.

Gatsby

Gatsby is a free and open-source framework based on React that helps developers build blazing fast websites and apps. It uses cutting edge technologies to make the process of building websites and applications more efficient. One of its key features is its ability to prefetch resources so that they are available instantaneously when needed. This makes Gatsby websites extremely fast and responsive. Another benefit of using Gatsby is that it allows developers to use GraphQL to query data from any source, making it easy to build complex data-driven applications. In addition, Gatsby comes with a number of plugins that make it even easier to use, including ones for SEO, analytics, and image optimization. All of these factors make Gatsby an extremely popular choice for building modern websites and applications.

Advantages: 

• Gatsby websites are extremely fast and responsive due to its use of prefetching.
• Gatsby makes it easy to build complex data-driven applications due to its support for GraphQL.
• Gatsby comes with a number of plugins that make it even easier to use.

Disadvantages: 

• While Gatsby is easy to use, it has a large learning curve if you want to master all its features.
• Gatsby does not have as many libraries and tools available as some of the other frameworks.

Nuxt.js

Nuxt.js is a progressive framework for building JavaScript applications. It is based on Vue.js and comes with a set of tools and libraries that make it easy to create universal applications that can be rendered on server-side and client-side. Nuxt.js also provides a way to handle asynchronous data and routing, which makes it perfect for building highly interactive applications. In addition, Nuxt.js comes with a CLI tool that makes it easy to scaffold new projects and build, run, and test them. With Nuxt.js, you can create impressive JavaScript applications that are fast, reliable, and scalable.

Advantages: 

• Nuxt.js is easy to use and extend.
• Nuxt.js applications are fast and responsive due to server-side rendering.

Disadvantages: 

• While Nuxt.js is easy to use, it has a large learning curve if you want to master all its features.
• Nuxt.js does not have as many libraries and tools available as some of the other frameworks.

Ember.js

Ember.js is known for its conventions over configuration approach which makes it easier for developers to get started with the framework. It also features built-in libraries for common tasks such as data persistence and routing which makes development faster.  Although Ember.js has a steep learning curve, it provides developers with a lot of flexibility and power to create rich web applications. If you’re looking for a front-end JavaScript framework to build SPAs, Ember.js is definitely worth considering.

Advantages:  

• Ember.js uses conventions over configuration which makes it easier to get started with the framework.
• Ember.js has built-in libraries for common tasks such as data persistence and routing.
• Ember.js provides developers with a lot of flexibility and power to create rich web applications.

Disadvantages: 

• Ember.js has a steep learning curve.
• Ember.js does not have as many libraries and tools available as some of the other frameworks.

Backbone.js

Backbone.js is a lightweight JavaScript library that allows developers to create single-page applications. It is based on the Model-View-Controller (MVC) architecture, which means that it separates data and logic from the user interface. This makes code more maintainable and scalable, as well as making it easier to create complex applications. Backbone.js also includes a number of features that make it ideal for developing mobile applications, such as its ability to bind data to HTML elements and its support for touch events. As a result, Backbone.js is a popular choice for developers who want to create fast and responsive applications.

Advantages:  

• Backbone.js is lightweight and only a library, not a complete framework.
• Backbone.js is easy to learn and use.
• Backbone.js is very extensible with many third-party libraries available.

Disadvantages: 

• Backbone.js does not offer as much built-in functionality as some of the other frameworks.
• Backbone.js has a smaller community than some of the other frameworks.

Conclusion

In conclusion, while there are many different JavaScript frameworks to choose from, the most popular ones remain relatively stable. Each has its own benefits and drawbacks that developers must weigh when making a decision about which one to use for their project. While no framework is perfect, each has something to offer that can make development easier or faster. 

Everyone should consider the specific needs of their project when choosing a framework, as well as the skills of their team and the amount of time they have to devote to learning a new framework. By taking all of these factors into account, you can choose the best JavaScript framework for your project!

If you’re reading this post, you probably already know enough about large language models and other “AI” tools, so we can skip the intro. 

Despite the fact that the “AI is going to take our jobs” discourse proved to be an effective tool in the clickbait content creators toolbelt, I will not take this road.

Instead of contributing to the moral panic about the supposedly inevitable replacement of white collar jobs, or pretending to be offended by a chatbot, I’ll help our readers to consider GPT-based products as tools that could be useful in a professional webdev setting. 

To do so, I asked some of my colleagues about their experiences of using GPT and various mutations of it – to help you get a more grounded understanding of their utility.

In case you have an experience that you consider useful sharing with the RisingStack community, please share it though this form. 

I’ll drop the results / best ones in the article later on!

Daniel’s  ‘Code GPT’ vscode plugin review

I’ve been pretty satisfied with GitHub Copilot. It does the job well, and it is priced reasonably. Still, after depleting the free tier, I decided to look for an open source alternative.

TabNine is an honorable mention here, and a well established player, but based on my previous experience (about two years ago, mind you), it is clunky. Nowhere near the breeze of a dev experience you get from Copilot.

But take heart, there is a staggering amount of plugins out there for VS Code, if you look for AI-based coding assistants. 

At the time of writing this, Code GPT is the winner by number of downloads, and number of (positive) votes, so I decided to give it a go. You can choose from a range of OpenAPI and Cohere models, with GPT-3 being the default.

Features:

1, Code Generation from comment prompts

The suggestions are relevant, and of quality. The plugin doesn’t offer code completion on the fly, unlike Copilot, but communicates with you in a new IDE pane it opens automatically instead. I like this feature, since I can pick the parts from the suggestion I liked, without bloating the code I’m working on, and having to delete the irrelevant lines. This behavior comes in handy with the other features as well. Let’s see those.

2, Unit Test generation

While the results are often far from being complete, it saves me a lot of boilerplate code. It is also handy in reminding me of cases that I otherwise might have forgotten. For this feature to work well, adjust your max token length to a 1000 at least in the Settings, since a comprehensive test suite usually ends up quite verbose, and you’ll only get part of it with a tight quota.

3, Find Problems

Your code review buddy. Once I feel I’m done with my work, a quick scan doesn’t take long before committing. While it often is straight out wrong about the ‘issues’ it points out, it doesn’t take long to scan through the suggestions, and catch mistakes before your real life reviewer does.

4, Refactor

Save some time for your team lead for extra credits, and run Refactor against your code. Don’t expect miracles to happen, but often times it catches stuff that managed to sneak under your radar. Note: the default max token length won’t cut it here either.

5, Document and Explain

Listed as two separate functionality in the documentation, it achieves essentially the same thing; provides a high level natural language description on what the highlighted peace of code does. I tend to use it less often, but it is a nice to have.

6, Ask CodeGPT

I left it the last, but this is the most flexible feature of this plugin. It can achieve all previously mentioned functionalities with the right prompt, and more. Convert your .js to .ts,  generate a README.md file from code, as suggested in the documentation, or just go ahead and ask for a recipe for a delicious apple pie, like you would from ChatGPT 🥧 

My Conclusion:

Code GPT offers many functionality that Copilot doesn’t, but lacks the thing Copilot is best at: inline code completion. So if you want to take the most out of AI, just use both, as these two tools complement each other really nice.

Code GPT Might come handy if you’re just getting started with a new language or framework. The Explain feature helps double-check your gut feeling, or gives you the missing hint in the right direction.

Bump up your max token length to at least a 1000, c’mon, it’s only ¢2 😉

An interesting alternative I might be trying in the future is ‘ChatGPT’ plugin (from either Tim Kmecl or Ali Gencay) that claims to be using the unofficial Chat GPT API, with all its superpowers.

Further reading:

– official site: https://www.codegpt.co/

– GitHub CoPilot vs ChatGPT: https://dev.to/ruppysuppy/battle-of-the-giants-github-copilot-vs-chatgpt-4oac

– List of GitHub CoPilot alternatives: https://www.tabnine.com/blog/github-copilot-alternatives/

Olga on writing Mongo queries with ChatGPT

I have used ChatGPT for more effective coding. It was really helpful for example with enhancing Mongo queries for more complex use cases as it suggested specific stages that worked for a use case, which would have definitely taken me more time to research and realize which stage and/or operator is ideal for this query. 

However all the answers it produces should be checked and not used blindly. I have not yet come across a case when the answer it provided didn’t need modification (though maybe it is due to the fact that I didn’t use it for easy things). 

I have also noticed that, if a question posted to ChatGPT includes many different parameters, in a lot of cases it will not take them all to consideration so one has to continue conversation and ensure all parameters are considered in the solution.

Akos on using ChatGPT instead of StackOverflow

I have been using ChatGPT since its inception and have found it to be a valuable tool in my daily work. With ChatGPT, I no longer have to spend hours searching and Googling for regex patterns on Stack Overflow. Instead, I simply write down what I want with the regex, and the tool returns the result, saving me a significant amount of time and effort.

In addition to regex, I have also found ChatGPT to be a valuable tool when working on scrapers. Dealing with deeply nested selectors can be a challenge, and understanding how they work with scraping tools can take hours of research. But with ChatGPT, I can simply paste an example HTML and ask the tool to select what I want, saving me even more time and effort.

However, it is important to use ChatGPT in moderation. Overusing the tool could lead to a decline in my problem-solving skills and make me too dependent on it. By setting limits, I can still benefit from ChatGPT’s time-saving features while maintaining my critical thinking skills.

In conclusion, ChatGPT has been a powerful tool in my work, saving me time and effort in regex and scraping tasks. However, it is important to use it in moderation and not let it compromise my problem-solving skills.

Me, Navigating the hallucinations of chatGPT

I work with a lot of text: business documents, project proposals, contracts, articles, marketing materials, you name it. I’ve been fascinated by the emergence of “AI” tools in 2022 and both the entertainment factor and the usefulness they can provide.

All big areas – text, voice, image – had huge releases that made the internet a very interesting place again after the boring years of the web3 / crypto / nft / metaverse nonsense. Suddenly I felt the rush of discovering the internet in the early 2000’s. “Wow, I can do that?!” was a sentence that got repeated a lot this year.

The Dall-E2 / Stable Diffusion / Whisper releases were more than enough to shake up the web, but ChatGPT was the one that really disrupted the web. The first good conversational “AI” that everyone could use, and for free (for now). At times it can be so convincing that people forget that it is just a very good bullshitter. For example when I ask it about RisingStack, I get the following answer:

“RisingStack is a software development and consulting company that specializes in building scalable, high-performance systems using Node.js, Kubernetes, and other modern web technologies. The company was founded in 2013 and is headquartered in Budapest, Hungary, with additional offices in London, United Kingdom, and New York, United States. RisingStack offers a range of services, including software development, architecture design, cloud infrastructure management, performance optimization, and training. They also develop open-source tools such as Trace, a Node.js performance monitoring and debugging tool, and Pino, a Node.js logging library. RisingStack has worked with a variety of clients, ranging from small startups to large enterprises, across a range of industries, including fintech, healthcare, e-commerce, and media. They are known for their expertise in Node.js and their commitment to delivering high-quality software solutions.”

Most of this text is usable, but it contains a lot of outright lies. It is important to keep in mind that GPT hallucinates. It has no idea about what is true and what is not. It pretends to know things, but it’s just making things up word by word. In this case: RisingStack was founded in 2014, and we never had a London office. Trace was sunset like 6 years ago, and Pino has nothing to do with us.

Anyways, I find it really useful when I need to generate / rephrase / improve text. It is only valid as a Google replacement if you can confidently tell if it’s right or wrong, so “geepeetee-ing” something is not really that helpful right now.

I already used it to write contracts, blog posts (not this one though), business proposals. It also brought in new clients, as just in the past couple of weeks we used it to..

• Automatically generate product names and descriptions for webshops
• Create easy-read text for children with disabilities
• Perform sentiment analysis and write answers automatically to customer reviews

Currently chatGPT has a lame writing style by default. It’s very formulaic. I’ve seen so much of it that I believe I can spot it 8 out of 10 times right away. It lies a lot, and I wasn’t able to get anything guitar-related useful out of it, despite the fact that the training material probably has a couple million tabs in it. 

Anyways, here are my not-so-hot takes to about it:

• You really need to carefully double check everything you generate. On the surface most of it might look good enough, but that’s just making it easier for everyone to get lazy with it.
• “AI” won’t replace jobs, instead, it will just improve productivity. As Photoshop is a better brush, GPT should be thought of as a better text/code editor. Most of the office jobs are about collaboration anyways, not typing on a keyboard.
• Artists won’t get replaced en masse. You won’t be able to prompt an engine to generate artwork in de Goya’s style, if cave paintings are the apex of your visual art knowledge. Taste will be very important to stand out when the web gets flooded with endless mediocre “art”. Also..
• It will be interesting to see how the “poisoning the well” problem will affect these models. The continuous retraining of the “AI” on already “AI generated” content will cause a big decline in the quality of these services, in case they won’t be able to filter them out… While they are working on making the generated content so good that it gets mistaken for genuine human creation.
• It’s a bit scary to think about how Microsoft will dominate this space through its OpenAI investment. Despite the genius branding, it is not open at all, and will cost a lot of money without serious competitors or general access to free-to-use alternatives (like Stable Diffusion for images).
• Most of the coverage GPT gets nowadays is about people gaming the engine to finally say something “bad”, then pretending to be offended, even more so, scared of it! This kind of AI ethics/alignment discourse is incredibly dull and boring, imho..
• Although the adversarial aspect is very interesting. Poisoning generally available chatbots training data will be a prime trolling activity, while convincing chatbots to spill their carefully crafted secret sauce prompts is something that needs to be continuously prevented.

I was first skeptical about prompt engineering as an emerging “profession”, but seeing how building products on top of GPT3 requires proper prompting and safeguards to make the end result consistently useful for end users, I can see it happening. Also, when you build something LLM driven, you need to be aware that hostile users, trolls, competitors, etc.. will try to game your product to ramp up your cloud costs or cause reputational harm.

This tweet really gets it.

This is already happening. Most of the “AI-driven” products are just purpose-repacked custom prompters calling GPT3 through an API, with a fancy UI.

Anyways, I’m looking forward to seeing what kind of GPT driven products we’ll make for our clients, and how the internet will change in general.

I’m curious about your experience with chatGPT, so please share it with me through this short form!

Cheers,

Ferenc

There are many different types of AI development tools available, but not all of them are created equal. Some tools are more suited for certain tasks than others, and it’s important to select the right tool for the job.

Choosing the wrong tool can lead to frustration and wasted time, so it’s important to do your research before you start coding. There are many different types of AI development tools available, so there’s sure to be one that fits your needs. Common types of AI development tools include cloud-based platforms, open source software, and low code development tools. 

Cloud-based platforms are typically the most user friendly and allow you to build sophisticated models quickly. They offer a wide variety of features, such as data analysis tools, natural language processing capabilities, automatic machine learning models creation and pre-trained models that can be used for various tasks.

Open-source software offers a great deal of flexibility and the ability to customize your AI model for specific tasks. However, using open source software requires coding knowledge and experience and is best suited for more experienced developers. 

Low code development tools allow you to create AI applications without having to write code. These tools allow developers of any skill level to quickly and easily create AI applications, eliminating the need for coding knowledge or experience. 

Of course, there are occasional overlaps, like cloud platforms using open-source technologies – but to find out all the similarities and differences, we’ll need to examine them. Let’s explore each one in further detail:

Detectron 2

Detectron 2 is Facebook’s state-of-the-art object detection and segmentation library. It features a number of pre-trained models and baselines that can be used for a variety of tasks, and it also has cuda bindings that allow it to run on gpu for even faster training. Compared to its predecessor, Detectron 2 is much faster to train and can achieve better performance on a variety of benchmarks. It is also open source and written in python, making it easy to use and extend. Overall, Detectron 2 is an excellent choice for any object detection or segmentation task.

The fact that it is built on PyTorch makes it very easy to share models between different use cases. For example, a model that is developed for research purposes can be quickly transferred to a production environment. This makes Detectron2 ideal for organizations that need to move quickly and efficiently between different use cases. In addition, the library’s ability to handle large-scale datasets makes it perfect for organizations that need to process large amounts of data. Overall, Detectron2 is an extremely versatile tool that can be used in a variety of different settings.

Caffe

Caffe is a deep learning framework for model building and optimisation. It was originally focused on vision applications, but it is now branching out into other areas such as sequences, reinforcement learning, speech, and text. Caffe is written in C++ and CUDA, with interfaces for python and mathlab. The community has built a number of models which are available at https://github.com/BVLC/caffe/wiki/Model-Zoo. Caffe is a powerful tool for anyone interested in deep learning.

It features fast, well-tested code and a seamless switch between CPU and GPU – meaning that if you don’t have a GPU that supports CUDA, it automatically defaults to the CPU. This makes it a versatile tool for deep learning researchers and practitioners. The Caffe framework is also open source, so anyone can contribute to its development.

Caffe offers the model definitions, optimization settings, and pre-trained weights so you can start right away. The BVLC models are licensed for unrestricted use, so you can use them in your own projects without any restrictions.

Keras

Keras is a deep learning framework that enables fast experimentation. It is based on Python and supports multiple backends, including TensorFlow, CNTK, and Theano. Keras includes specific tools for computer vision (KerasCV) and natural language processing (KerasNLP). Keras is open source and released under the MIT license.

The idea behind Keras is to provide a consistent interface to a range of different neural network architectures, allowing for easy and rapid prototyping. It is also possible to run Keras models on top of other lower-level frameworks such as MXNet, Deeplearning4j, TensorFlow or Theano. Keras, like other similar tools, has the advantage of being able to run on both CPU and GPU devices with very little modification to the code.

In addition, Keras includes a number of key features such as support for weight sharing and layer reuse, which can help to improve model performance and reduce training time.

CUDA

The CUDA toolkit is a powerful set of tools from NVIDIA for running code on GPUs. It includes compilers, libraries, and other necessary components for developing GPU-accelerated applications. The toolkit supports programming in Python, C, and C++, and it makes it easy to take advantage of the massive parallel computing power of GPUs. With the CUDA toolkit, you can accelerate your code to run orders of magnitude faster than on a CPU alone. Whether you’re looking to speed up machine learning algorithms or render complex 3D graphics, the CUDA toolkit can help you get the most out of your NVIDIA GPUs.

In the context of fraud detection, the CUDA toolkit can be used to train graph neural networks (GNNs) on large datasets in an efficient manner. This allows GNNs to learn from more data, which can lead to improved performance. In addition, the CUDA toolkit can be used to optimize the inference process, which is important for real-time applications such as fraud detection, which is a critical application for machine learning. Many techniques struggle with fraud detection because they cannot easily identify patterns that span multiple transactions. However, GNNs are well-suited to this task due to their ability to aggregate information from the local neighborhood of a transaction. This enables them to identify larger patterns that may be missed by traditional methods.

TensorFlow

TensorFlow is an open-source platform for machine learning that offers a full pipeline from model building to deployment. It has a large collection of pre-trained models and supports a broad range of programming languages including Javascript, Python, Android, Swift, C++, and Objective C. TensorFlow uses the Keras API and also supports CUDA for accelerated training on NVIDIA GPUs. In addition to providing tools for developers to build and train their own models, TensorFlow also offers a wide range of resources such as tutorials and guides.

TensorFlow.js is a powerful tool that can be used to solve a variety of problems. In the consumer packaged goods (CPG) industry, one of the most common problems is real-time and offline SKU detection. This problem is often caused by errors in manually inputting data, such as when a product is scanned at a store or when an order is placed online. TensorFlow.js can be used to create a solution that would automatically detect and correct these errors in real time, as well as provide offline support for cases where a connection is not available. This can greatly improve the efficiency of the CPG industry and reduce the amount of waste caused by incorrect data input.

PyTorch

PyTorch is a powerful machine learning framework that allows developers to create sophisticated applications for computer vision, audio processing, and time series analysis. The framework is based on the popular Python programming language, and comes with a large number of libraries and frameworks for easily creating complex models and algorithms. PyTorch also supports bindings for c++ and java, making it a great option for cross-platform development. In addition, the framework includes CUDA support for accelerated computing on NVIDIA GPUs. And finally, PyTorch comes with a huge collection of pre-trained models that can be used for quickly building sophisticated applications.

PyTorch’s ease of use and flexibility make it a popular choice for researchers and developers alike. The PyTorch framework is known to be convenient and flexible, with examples covering reinforcement learning, image classification, and natural language processing as the more common use cases. As a result, it is no surprise that the framework has been gaining popularity in recent years. Thanks to its many features and benefits, PyTorch looks poised to become the go-to framework for deep learning in the years to come.

Apache MXNet

MXNet is an open-source deep learning framework that allows you to define, train, and deploy deep neural networks on a wide array of devices, from cloud infrastructure to mobile devices. It’s scalable, allowing for fast model training, and supports a flexible programming model and multiple languages.

It’s built on a dynamic dependency scheduler that automatically parallelizes both symbolic and imperative operations on the fly. A graph optimization layer makes symbolic execution fast and memory efficient.

The MXNet library is portable and lightweight. It’s accelerated with the NVIDIA Pascal™ GPUs and scales across multiple GPUs and multiple nodes, allowing you to train models faster. Whether you’re looking to build state-of-the-art models for image classification, object detection, or machine translation, MXNet is the tool for you.

Horovod

Horovod is a distributed training framework for deep learning that supports TensorFlow, Keras, PyTorch, and Apache MXNet. It is designed to make distributed training easy to use and efficient. Horovod uses a message passing interface to communicate between nodes, and each node runs a copy of the training script. The framework handles the details of communication and synchronization between nodes so that users can focus on their model. Horovod also includes a number of optimizations to improve performance, such as automatically fusing small tensors together and using hierarchical allreduce to reduce network traffic.

For Uber’s data scientists, the process of installing TensorFlow was made even more challenging by the fact that different teams were using different releases of the software. The team wanted to find a way to make it easier for all teams to use the ring-allreduce algorithm, without requiring them to upgrade to the latest version of TensorFlow or apply patches to their existing versions. The solution was to create a stand-alone package called Horovod. This package allowed the team to cut the time required to install TensorFlow from about an hour to a few minutes, depending on the hardware. As a result, Horovod has made it possible for Uber’s data scientists to spend less time installing software and more time doing what they do best.

Oracle AI

Oracle AI is a suite of artificial intelligence services that can be used to build, train and deploy models. The services include natural language processing, chat bots / customer support, text-to-speech, speech-to-text, object detection for images and data mining. Oracle AI offers pre-configured vms with access to GPUs. The service can be used to build models for anomaly detection, analytics and data mining. Oracle AI is a powerful tool that can be used to improve your business.

Children’s Medical Research Institute (CMRI) is a not-for-profit organisation dedicated to improving the health of children through medical research. CMRI moved to Oracle Cloud Infrastructure (OCI) as its preferred cloud platform. This move has helped the institute take advantage of big data and machine learning capabilities to automate routine database tasks, database consolidation, operational reporting, and batch data processing. Overall, the switch to OCI has been a positive move for CMRI, and one that is sure to help the institute continue its important work.

H2O

H2O is a powerful open source AI platform that is used by companies all over the world to improve their customer support, marketing, and data mining efforts. The software provides a wide range of features that make it easy to collect and analyze customer data, identify anomalies, and create chat bots that can provide an engaging customer experience. H2O is constantly evolving, and the company behind it is always introducing new features and improvements.

For example, it can be used to create an intelligent cash management system that predicts cash demand and helps to optimize ATM operations. It can also help information security teams reduce risk by identifying potential threats and vulnerabilities in real time. In addition, H2O.AI can be used to transform auditing from quarterly to real-time, driving audit quality, accuracy and reliability.

Alibaba Cloud

Alibaba Cloud is a leading provider of cloud computing services. Its products include machine learning, natural language processing, data mining, and analytics. Alibaba Cloud’s machine learning platform offers a variety of pre-created algorithms that can be used for tasks such as data mining, anomaly detection, and predictive maintenance. The platform also provides tools for training and deploying machine learning models. Alibaba Cloud’s natural language processing products offer APIs for text analysis, voice recognition, and machine translation. The company’s data mining and analytics products provide tools for exploring and analyzing data. Alibaba Cloud also offers products for security, storage, and networking.

Alibaba, the world’s largest online and mobile commerce company, uses intelligent recommendation algorithms to drive sales using personalized customer search suggestions on its Tmall homepage and mobile app. The system takes into account a customer’s purchase history, browsing behavior, and social interactions when making recommendations. Alibaba has found that this approach leads to increased sales and higher customer satisfaction. In addition to search suggestions, the system also provides personalized product recommendations to customers based on their past behavior. This has resulted in increased sales and engagement on the platform. Alibaba is constantly tweaking and improving its algorithms to ensure that it is providing the most relevant and useful data to its users.

IBM Watson

IBM Watson is a powerful artificial intelligence system that has a range of applications in business and industry. One of the most important functions of Watson is its ability to process natural language. This enables it to understand human conversation and respond in a way that sounds natural. This capability has been used to develop chatbots and customer support systems that can replicate human conversation. In addition, Watson’s natural language processing capabilities have been used to create marketing campaigns that can target specific demographics. Another key application of Watson is its ability to detect anomalies. This makes it an essential tool for monitoring systems and identifying potential problems. As a result, IBM Watson is a versatile and valuable artificial intelligence system with a wide range of applications.

IBM Watson is employed in nearly every industry vertical, as well as in specialized application areas such as cybersecurity. This technology is often used by a company’s data analytics team, but Watson has become so user friendly that it is also easily used by end users such as physicians or marketers.

Azure AI

Azure AI is a suite of services from Microsoft that helps you build, optimize, train, and deploy models. You can use it for object detection in images and video, natural language processing, chatbots and customer support, text-to-speech, speech-to-text, data mining and analytics, and anomaly detection. Azure AI also provides pre-configured virtual machines so you can get started quickly and easily. Whether you’re an experienced data scientist or just getting started with machine learning, Azure AI can help you achieve your goals.

With the rapid pace of technological advancement, it is no surprise that the aviation industry is constantly evolving. One of the leading companies at the forefront of this change is Airbus. The company has unveiled two new innovations that utilize Azure AI solutions to revolutionize pilot training and predict aircraft maintenance issues.

Google AI

Google AI is a broad set of tools and services that helps you build, deploy, and train models, as well as to take advantage of pre-trained models. You can use it to detect objects in images and video, to perform natural language processing tasks such as chat bots or customer support, to translate text, and to convert text-to-speech or speech-to-text. Additionally, Google AI can be used for data mining and analytics, as well as for anomaly detection. All of these services are hosted on Google Cloud Platform, which offers a variety of options for GPU-accelerated computing, pre-configured virtual machines, and TensorFlow hosting.

UPS and Google Cloud Platform were able to develop routing software that has had a major impact on the company’s bottom line. The software takes into account traffic patterns, weather conditions, and the location of UPS facilities, in order to calculate the most efficient route for each driver. As a result, UPS has saved up to $400 million a year, and reduced its fuel consumption by 10 million gallons. In addition, the software has helped to improve customer satisfaction by ensuring that packages are delivered on time.

AWS AI

Amazon Web Services offers a variety of AI services to help developers create intelligent applications. With pre-trained models for common use cases, AWS AI makes it easy to get started with machine learning. For images and video, the object detection service provides accurate labels and coordinates. Natural language processing can be used for chat bots and customer support, as well as translation. Text-to-speech and speech-to-text are also available. AI powered search provides relevant results from your data. Pattern recognition can be used for code review and monitoring. And data mining and analytics can be used for anomaly detection. AWS AI also offers hosted GPUs and pre-configured vms. With so many powerful features, Amazon Web Services is the perfect platform for developing AI applications.

Formula 1 is the world’s most popular motorsport, with hundreds of millions of fans worldwide. The sport has been at the forefront of technological innovation for decades, and its use of data and analytics has been central to its success. Teams have long used on-premises data centers to store and process large amounts of data, but the sport is now accelerating its transformation to the cloud. Formula 1 is moving the vast majority of its infrastructure to Amazon Web Services (AWS), and standardizing on AWS’s machine-learning and data-analytics services. This will enable Formula 1 to enhance its race strategies, data tracking systems, and digital broadcasts through a wide variety of AWS services—including Amazon SageMaker, AWS Lambda, and AWS’s event-driven serverless computing service. By using these services, Formula 1 will be able to deliver new race metrics that will change the way fans and teams experience racing.

Conclusion

Choosing the right AI development tool can be difficult. This article has provided a comparison of some of the most popular tools on the market. Each tool has its own strengths and weaknesses, so it is important to decide which one will best suit your needs.

Are you currently preparing for a Kubernetes interview? If so, you’ll want to make sure you’re familiar with the questions and answers below at least. This article will help you demonstrate your understanding of Kubernetes concepts and how they can be applied in practice. With enough preparation, you’ll be able to confidently nail your next interview and showcase your Kubernetes skills. Let’s get started!

What is Kubernetes?

Kubernetes is a platform for managing containerized stateless or stateful applications across a cluster of nodes. Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It groups containers that make up an application into logical units for easy management and discovery. Kubernetes also automates the replication of the containers across multiple nodes in a cluster, as well as healing of failed containers. Kubernetes was originally designed by Google, and is now maintained by the Cloud Native Computing Foundation.

Some of the key features of Kubernetes include:

– Provisioning and managing containers across multiple hosts

– Scheduling and deploying containers

– Orchestrating containers as part of a larger application

– Automated rollouts and rollbacks

– Handling container health and failure

– Scaling containers up and down as needed

– It has a large and active community that develops new features and supports users.

– It has a variety of tools for managing storage and networking for containers. 

What are the main differences between Docker Swarm and Kubernetes?

Docker Swarm and Kubernetes are both container orchestration platforms. They are both designed for deploying and managing containers at scale. However, there are some key differences between the two platforms.

Docker Swarm is a native clustering solution for Docker. It is simpler to install and configure than Kubernetes. Docker Swarm also uses the same CLI and API as Docker, so it is easy to learn for users who are already familiar with Docker. However, Docker Swarm lacks some of the advanced features that Kubernetes has, such as automatic rollouts and rollbacks, health checks, and secrets management.

Kubernetes is a more complex system than Docker Swarm, but it offers a richer feature set. Kubernetes is also portable across different environments, so it can be used in on-premise deployments, as well as cloud-based deployments. In addition, Kubernetes is backed by a large community of users and developers, so there is a wealth of support and documentation available.

To sum up:

-Kubernetes is more complicated to set up but the benefits are a robust cluster and auto-scaling 

-Docker Swarm is easy to set up but does not have a robust cluster or autoscaling 

What is a headless service?

​​A headless service is a special type of Kubernetes service that does not expose a cluster IP address. This means that the service will not provide load balancing to the associated pods. Headless services are useful for applications that require a unique IP per instance or for applications that do not require load balancing. For example, stateful applications such as databases often require a unique IP address per instance. By using a headless service, each instance can be given its own IP address without the need for a load balancer. Headless services can also be used to expose individual instances of an application outside of the Kubernetes cluster. This is often done by using a tool like kubectl to expose individual pods.

What are the main components of Kubernetes architecture?

Pods and containers are two components of a Kubernetes architecture. Pods are composed of one or more containers that share an IP address and port space. This means that containers within a pod can communicate with each other without going through a network. Pods also provide a way to deploy applications on a cluster in a replicable and scalable way. Containers, on the other hand, are isolated from each other and do not share an IP address. This isolation provides a higher level of security as each container can only be accessed by its own process. In addition, containers have their own file system, which means that they can be used to package up an application so that it can be run in different environments.

What are the different management and orchestrator features in Kubernetes?

The available management and orchestrator features in Kubernetes are: 

1. Cluster management components: These components manage the Kubernetes cluster.

2. Container orchestration components: These components orchestrate the deployment and operation of containers.

3. Scheduling components: These components schedule and manage the deployment of containers on nodes in the cluster.

4. Networking components: These components provide networking capabilities for containers in the cluster.

5. Storage components: These components provide storage for containers in the cluster.

6. Security components: These components provide security for the containers in the cluster.

What is the load balancer in Kubernetes?

A load balancer is a software program that evenly distributes network traffic across a group of servers. It is used to improve the performance and availability of applications that run on multiple servers.

Specifically, the load balancer in Kubernetes is a component that distributes traffic across nodes in a Kubernetes cluster. It can be used to provide high availability and to optimize resource utilization. Also, the load balancer can help to prevent overloads on individual nodes. 

What is Container resource monitoring?

Container resource monitoring means that you can keep track of CPU, Memory, and Disk space utilization for each container in your Kubernetes cluster. There are a two main ways to monitor the Kubernetes cluster. One way is to use the built-in kubectl command-line interface: this is able to monitor CPU utilization, memory usage and disk space. If you need to keep track of more data, then there’s another way: to use a third-party monitoring tool such as Datadog, New Relic, or Prometheus. 

What is the difference between a ReplicaSet and replication controller?

In Kubernetes, a ReplicaSet is a collection of pods that are always up and running. The replication controller’s objectives are to ensure that a desired number of pod replicas are running at all times, and to maintain the desired state of the pods in the system.

A ReplicaSet is a newer, more advanced concept that replaces replication controllers. A ReplicaSet allows you to define a minimum number of pods that must be up and running at all times, and provides a richer set of features than replication controllers.

ReplicaSets are the basic building blocks of Kubernetes clusters. They provide the ability to have multiple copies of an application running in parallel, and to scale out (add more nodes) or scale in (remove nodes) the number of copies as needed. Replication controllers provide the ability to maintain a desired number of pod replicas for a particular application.

A ReplicaSet ensures that a specified number of pod replicas are running at any given time. However, a Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to Pods along with a lot of other useful features. Therefore, we recommend using Deployments instead of directly using ReplicaSets, unless you require custom update orchestration or don’t require updates at all.

What are the recommended security measures for Kubernetes?

There are a number of recommended security measures for Kubernetes, including implementing third-party authentication and authorization tools, using network segmentation to restrict access to sensitive data, and maintaining regular monitoring and auditing of the cluster.

Another key recommendation is to use role-based access control (RBAC) to limit access to the Kubernetes API. This ensures that only authorized users can make changes to the system and introduces an additional layer of protection against potential vulnerabilities or attacks.

Node isolation is also worth mentioning. It is a process of isolating individual nodes in a Kubernetes cluster so that each node only has access to its own resources. This process is used to improve the security and performance of Kubernetes clusters by preventing malicious activity on one node from affecting other nodes. Node isolation can be achieved through a variety of means, such as using a firewall to block network traffic between nodes, or using software-defined networking to segment node traffic. By isolating nodes, Kubernetes administrators can ensure that each node in a cluster is used only for its intended purpose and that unauthorized access to resources is prevented.

Other best practices for securing Kubernetes include: 

– Restricting access to the Kubernetes API to authorized users only

– Using network firewalls to restrict access to the Kubernetes nodes from unauthorized users

– Using intrusion detection/prevention systems to detect and prevent unauthorized access to the Kubernetes nodes

– Using encryption for communications between the nodes and pods in the cluster

– Limiting which IP addresses have access to cluster resources

– Implementing regular vulnerability assessments.

Ultimately, incorporating these types of security measures into your Kubernetes deployment will help ensure the safety and integrity of your system.

What is Container Orchestration and how does it work in Kubernetes?

Container orchestration is the process of managing a group of containers as a single entity. Container orchestration systems, like Kubernetes, allow you to deploy and manage containers across a cluster of nodes. This provides a higher-level of abstraction and makes it easier to manage and scale your applications.

Kubernetes supports features for container orchestration, including:

– Creating and managing containers

– Configuring and managing networking

– Configuring and managing storage

– Booting and managing VMs

– Deploying applications

– Managing workloads

– Accessing logs and monitoring resources

– Configuring security and authentication

What are the features of Kubernetes?

Kubernetes is a platform that enables users to deploy, manage and scale containerized applications. Some of its key features include:

-Declarative syntax: Kubernetes uses a declarative syntax that makes it easy to describe the desired state of an application.

-Self-healing: Kubernetes is able to automatically heal applications and nodes in the event of failures.

-Horizontal scalability: Kubernetes enables users to scale their applications horizontally, by adding or removing nodes as needed.

-Fault tolerance: Kubernetes is able to tolerate failures of individual nodes or pods, ensuring that applications are always available.

What is Kube-apiserver and what’s the role of it?

The Kubernetes apiserver is a critical part of a Kubernetes deployment.

The apiserver provides a REST API for managing Kubernetes resources.

It also provides authentication and authorization for accessing those resources.

The apiserver must be secured to prevent unauthorized access to Kubernetes resources.

Use role-based access control to restrict access to specific resources.

What is a node in Kubernetes?

A node is a master or worker machine in Kubernetes. It can be a physical machine or a virtual machine.

A node is a member of a Kubernetes cluster. Each node in a Kubernetes cluster is assigned a unique ID, which is used to identify the node when communicating with the Kubernetes API.

When a new node is added to a Kubernetes cluster, the Kubernetes API is contacted to register the node with the cluster. The Kubernetes API stores information about the node, including its assigned ID, the addresses of the node’s Kubernetes masters, and the labels assigned to the node.

When a node is removed from a Kubernetes cluster, the Kubernetes API is contacted to unregister the node from the cluster. The Kubernetes API removes information about the node from its database, including the node’s assigned ID, the addresses of the node’s Kubernetes masters, and the labels assigned to the node.

What is kube-scheduler and what’s the role of it?

Kube-scheduler is responsible for keeping track of the state of the cluster and ensuring that all desired pods are scheduled.

In a Kubernetes cluster, the scheduler is responsible for assigning Pods to Nodes. 

When a new Pod is created, the scheduler watches for it and becomes responsible for finding the best Node for that Pod to run on. To do this, the scheduler looks at the requirements of the Pod and compares them with the capabilities of the Nodes in the cluster. The scheduler also takes into account factors such as Node utilization and available resources. By finding the best match between Pods and Nodes, the scheduler helps to ensure that Pods are running on an optimal Node. This, in turn, helps to improve the performance of the overall cluster.

To get the most out of the Kubernetes scheduler, you should configure it to schedule your pods as efficiently as possible. You can do this by configuring the scheduler’s resource constraints and pod priorities.

What is Minikube?

Minikube is important because it allows you to have a local Kubernetes environment. Minikube is a single node Kubernetes environment that you can install on your laptop. This is important because it allows you to develop and test Kubernetes applications without having to deploy them to a cluster.

What is a Namespace in Kubernetes?

Namespaces are a way to logically group objects in Kubernetes. By default, Kubernetes has a single namespace. Objects in different namespaces can have different security contexts and can be managed independently.

How can you handle incoming data from external sources (ingress traffic)?

Ingress is a Kubernetes resource that allows an organization to control how external traffic is routed to and from its services. Ingress resources are defined in a YAML file. An Ingress controller is then deployed to manage the ingress resource.

Ingress controllers use the Ingress Resource Definition to determine how to route traffic to services.

Ingress controllers can use a variety of methods to route traffic, including:

-Using a load balancer

-Using a DNS server

-Using a path-based routing algorithm

What are federated clusters?

Federated clusters in Kubernetes allow multiple Kubernetes clusters to be interconnected, forming a larger mesh of clusters. This allows for greater scale and redundancy, as well as simplified management of multiple clusters.

Federated clusters are configured by setting up a federated control plane, and then adding other Kubernetes clusters to the federated control plane. The federated control plane can be used to manage the other Kubernetes clusters in a number of ways, including:

• The nodes in the other clusters
• The Pods in the other clusters
• The Services in the other clusters
• The Secrets in the other clusters
• The ConfigMaps in the other clusters
• The Deployments in the other clusters
• The ReplicationControllers in the other clusters
• The Ingresses in the other clusters
• The LoadBalancers in the other clusters

What is a Kubelet?

Kubelet is a daemon on each node that runs on each Kubernetes node. Kubelet is responsible for communicating with the API server to get information about the state of the nodes and pods in the cluster, and for pulling and pushing images to and from the nodes.

What is Kubectl?

Kubectl is a command-line interface for Kubernetes. With Kubectl, you can manage your Kubernetes clusters and applications. Kubectl can be used on your local machine, or you can use it with a Kubernetes cluster. kubectl can be used to create, delete, and manage Kubernetes objects.

What is Kube-proxy? 

Kube-proxy is a daemon that runs on each Kubernetes node. It is responsible for proxying pod IPs and service IPs to the correct pods and services.  Kube-proxy is started automatically by Kubernetes.  Kubernetes also uses kube-proxy to load balance services. 

What are “K8s”? 

k8s is an abbreviation for Kubernetes.

How are Kubernetes and Docker related?

Kubernetes is a platform for managing containers at scale, while Docker itself is a container technology that can be used by Kubernetes.

A container infrastructure, such as Docker, allows apps to be packaged into lightweight, portable, and self-sufficient units. Kubernetes is a platform for managing and orchestrating containers at scale. Along with Kubernetes, Docker gives you the ability to deploy and manage applications at large scales.

Conclusion

The interview process can be daunting, but by preparing for the most commonly asked questions and understanding the basics of what Kubernetes is and does, you’ll be well on your way to acing your interview. We wish you the best of luck in your upcoming interview!

Redwood and Blitz are two up-and-coming full-stack meta-frameworks that provide tooling for creating SPAs, server-side rendered pages, and statically generated content, providing a CLI to generate end-to-end scaffolds. I’ve been waiting for a worthy Rails replacement in JavaScript since who-knows-when. This article is an overview of the two, and while I’ve given more breadth to Redwood (as it differs from Rails a great deal), I personally prefer Blitz.

As the post ended up being quite lengthy, below, we provide a comparison table for the hasty ones.

A bit of history first

If you started working as a web developer in the 2010s, you might not have even heard of Ruby on Rails, even though it gave us apps like Twitter, GitHub, Urban Dictionary, Airbnb, and Shopify. Compared to the web frameworks of its time, it was a breeze to work with. Rails broke the mold of web technologies by being a highly opinionated MVC tool, emphasizing the use of well-known patterns such as convention over configuration and DRY, with the addition of a powerful CLI that created end-to-end scaffolds from model to the template to be rendered. Many other frameworks have built on its ideas, such as Django for Python, Laravel for PHP, or Sails for Node.js. Thus, arguably, it is a piece of technology just as influential as the LAMP stack before its time.

However, the fame of Ruby on Rails has faded quite a bit since its creation in 2004. By the time I started working with Node.js in 2012, the glory days of Rails were over. Twitter — built on Rails — was infamous for frequently showcasing its fail whale between 2007 and 2009. Much of it was attributed to the lack of Rails’ scalability, at least according to word of mouth in my filter bubble. This Rails bashing was further reinforced when Twitter switched to Scala, even though they did not completely ditch Ruby then.

The scalability issues of Rails (and Django, for that matter) getting louder press coverage coincided with the transformation of the Web too. More and more JavaScript ran in the browser. Webpages became highly interactive WebApps, then SPAs. Angular.js revolutionized that too when it came out in 2010. Instead of the server rendering the whole webpage by combining the template and the data, we wanted to consume APIs and handle the state changes by client-side DOM updates.

Thus, full-stack frameworks fell out of favor. Development got separated between writing back-end APIs and front-end apps. And these apps could have meant Android and iOS apps too by that time, so it all made sense to ditch the server-side rendered HTML strings and send over the data in a way that all our clients could work with.

UX patterns developed as well. It wasn’t enough anymore to validate the data on the back-end, as users need quick feedback while they’re filling out bigger and bigger forms. Thus, our life got more and more complicated: we needed to duplicate the input validations and type definitions, even if we wrote JavaScript on both sides. The latter got simpler with the more widespread (re-)adoption of monorepos, as it got somewhat easier to share code across the whole system, even if it was built as a collection of microservices. But monorepos brought their own complications, not to mention distributed systems.

And ever since 2012, I have had a feeling that whatever problem we solve generates 20 new ones. You could argue that this is called “progress”, but maybe merely out of romanticism, or longing for times past when things used to be simpler, I’ve been waiting for a “Node.js on Rails” for a while now. Meteor seemed like it could be the one, but it quickly fell out of favor, as the community mostly viewed it as something that is good for MVPs but does not scale… The Rails problem all over again, but breaking down at an earlier stage of the product lifecycle. I must admit, I never even got around to try it.

However, it seemed like we were getting there slowly but steadily. Angular 2+ embraced the code generators á la Rails, alongside with Next.js, so it seemed like it could be something similar. Next.js got API Routes, making it possible to handle the front-end with SSR and write back-end APIs too. But it still lacks a powerful CLI generator and has nothing to do with the data layer either. And in general, a good ORM was still missing from the equation to reach the power level of Rails. At least this last point seems to be solved with Prisma being around now.

Wait a minute. We have code generators, mature back-end and front-end frameworks, and finally, a good ORM. Maybe we have all pieces of the puzzle in place? Maybe. But first, let’s venture a bit further from JavaScript and see if another ecosystem has managed to further the legacy of Rails, and whether we can learn from it.

Enter Elixir and Phoenix

Elixir is a language built on Erlang’s BEAM and OTP, providing a nice concurrency model based on the actor model and processes, which also results in easy error handling due to the “let it crash” philosophy in contrast to defensive programming. It also has a nice, Ruby-inspired syntax, yet remains to be an elegant, functional language.

Phoenix is built on top of Elixir’s capabilities, first as a simple reimplementation of Rails, with a powerful code generator, an data mapping toolkit (think ORM), good conventions, and generally good dev experience, with the inbuilt scalability of the OTP.

Yeah.. So far, I wouldn’t have even raised an eyebrow. Rails got more scalable over time, and I can get most of the things I need from a framework writing JavaScript these days, even if wiring it all up is still pretty much DIY. Anyhow, if I need an interactive browser app, I’ll need to use something like React (or at least Alpine.js) to do it anyway.

Boy, you can’t even start to imagine how wrong the previous statement is. While Phoenix is a full-fledged Rails reimplementation in Elixir, it has a cherry on top: your pages can be entirely server-side rendered and interactive at the same time, using its superpower called LiveView. When you request a LiveView page, the initial state gets prerendered on the server side, and then a WebSocket connection is built. The state is stored in memory on the server, and the client sends over events. The backend updates the state, calculates the diff, and sends over a highly compressed changeset to the UI, where a client-side JS library updates the DOM accordingly.

I heavily oversimplified what Phoenix is capable of, but this section is already getting too long, so make sure to check it out yourself!

We’ve taken a detour to look at one of the best, if not the best full-stack frameworks out there. So when it comes to full-stack JavaScript frameworks, it only makes sense to achieve at least what Phoenix has achieved. Thus, what I would want to see:

1. A CLI that can generate data models or schemas, along with their controllers/services and their corresponding pages
2. A powerful ORM like Prisma
3. Server-side rendered but interactive pages, made simple
4. Cross-platform usability: make it easy for me to create pages for the browser, but I want to be able to create an API endpoint responding with JSON by just adding a single line of code.
5. Bundle this whole thing together

With that said, let’s see whether Redwood or Blitz is the framework we have been waiting for.

What is RedwoodJS?

Redwood markets itself as THE full-stack framework for startups. It is THE framework everyone has been waiting for, if not the best thing since the invention of sliced bread. End of story, this blog post is over.

At least according to their tutorial.

I felt a sort of boastful overconfidence while reading the docs, which I personally find difficult to read. The fact that it takes a lighter tone compared to the usual, dry, technical texts is a welcome change. Still, as a text moves away from the safe, objective description of things, it also wanders into the territory of matching or clashing with the reader’s taste. 

In my case, I admire the choice but could not enjoy the result.

Still, the tutorial is worth reading through. It is very thorough and helpful. The result is also worth the… well, whatever you feel while reading it, as Redwood is also nice to work with. Its code generator does what I would expect it to do. Actually, it does even more than I expected, as it is very handy not just for setting up the app skeleton, models, pages, and other scaffolds. It even sets your app up to be deployed to different deployment targets like AWS Lambdas, Render, Netlify, Vercel.

Speaking of the listed deployment targets, I have a feeling that Redwood pushes me a bit strongly towards serverless solutions, Render being the only one in the list where you have a constantly running service. And I like that idea too: if I have an opinionated framework, it sure can have its own opinions about how and where it wants to be deployed. As long as I’m free to disagree, of course.

But Redwood has STRONG opinions not just about the deployment, but overall on how web apps should be developed, and if you don’t agree with those, well…

I want you to use GraphQL

Let’s take a look at a freshly generated Redwood app. Redwood has its own starter kit, so we don’t need to install anything, and we can get straight to creating a skeleton.

$ yarn create redwood-app --ts ./my-redwood-app

You can omit the --ts flag if you want to use plain JavaScript instead.

Of course, you can immediately start up the development server and see that you got a nice UI already with yarn redwood dev. One thing to notice, which is quite commendable in my opinion, is that you don’t need to globally install a redwood CLI. Instead, it always remains project local, making collaboration easier.

Now, let’s see the directory structure.

my-redwood-app
├── api/
├── scripts/
├── web/
├── graphql.config.js
├── jest.config.js
├── node_modules
├── package.json
├── prettier.config.js
├── README.md
├── redwood.toml
├── test.js
└── yarn.lock

We can see the regular prettier.config.js, jest.config.js, and there’s also a redwood.toml for configuring the port of the dev-server. We have an api and web directory for separating the front-end and the back-end into their own paths using yarn workspaces.

But wait, we have a graphql.config.js too! That’s right, with Redwood, you’ll write a GraphQL API. Under the hood, Redwood uses Apollo on the front-end and Yoga on the back-end, but most of it is made pretty easy using the CLI. However, GraphQL has its downsides, and if you’re not OK with the tradeoff, well, you’re shit out of luck with Redwood.

Let’s dive a bit deeper into the API.

my-redwood-app
├── api
│   ├── db
│   │   └── schema.prisma
│   ├── jest.config.js
│   ├── package.json
│   ├── server.config.js
│   ├── src
│   │   ├── directives
│   │   │   ├── requireAuth
│   │   │   │   ├── requireAuth.test.ts
│   │   │   │   └── requireAuth.ts
│   │   │   └── skipAuth
│   │   │       ├── skipAuth.test.ts
│   │   │       └── skipAuth.ts
│   │   ├── functions
│   │   │   └── graphql.ts
│   │   ├── graphql
│   │   ├── lib
│   │   │   ├── auth.ts
│   │   │   ├── db.ts
│   │   │   └── logger.ts
│   │   └── services
│   ├── tsconfig.json
│   └── types
│       └── graphql.d.ts
...

Here, we can see some more, backend related config files, and the debut of tsconfig.json.

• api/db/: Here resides our schema.prisma, which tells us the Redwood, of course, uses Prisma. The src/ dir stores the bulk of our logic.
• directives/: Stores our graphql schema directives.
• functions/: Here are the necessary lambda functions so we can deploy our app to a serverless cloud solution (remember STRONG opinions?).
• graphql/: Here reside our gql schemas, which can be generated automatically from our db schema.
• lib/: We can keep our more generic helper modules here.
• services/: If we generate a page, we’ll have a services/ directory, which will hold our actual business logic.

This nicely maps to a layered architecture, where the GraphQL resolvers function as our controller layer. We have our services, and we can either create a repository or dal layer on top of Prisma, or if we can keep it simple, then use it as our data access tool straight away.

So far so good. Let’s move to the front-end.

my-redwood-app
├── web
│   ├── jest.config.js
│   ├── package.json
│   ├── public
│   │   ├── favicon.png
│   │   ├── README.md
│   │   └── robots.txt
│   ├── src
│   │   ├── App.tsx
│   │   ├── components
│   │   ├── index.css
│   │   ├── index.html
│   │   ├── layouts
│   │   ├── pages
│   │   │   ├── FatalErrorPage
│   │   │   │   └── FatalErrorPage.tsx
│   │   │   └── NotFoundPage
│   │   │       └── NotFoundPage.tsx
│   │   └── Routes.tsx
│   └── tsconfig.json
...

From the config file and the package.json, we can deduce we’re in a different workspace. The directory layout and file names also show us that this is not merely a repackaged Next.js app but something completely Redwood specific.

Redwood comes with its router, which is heavily inspired by React Router. I found this a bit annoying as the dir structure-based one in Next.js feels a lot more convenient, in my opinion.

However, a downside of Redwood is that it does not support server-side rendering, only static site generation. Right, SSR is its own can of worms, and while currently you probably want to avoid it even when using Next, with the introduction of Server Components this might soon change, and it will be interesting to see how Redwood will react (pun not intended).

On the other hand, Next.js is notorious for the hacky way you need to use layouts with it (which will soon change though), while Redwood handles them as you’d expect it. In Routes.tsx, you simply need to wrap your Routes in a Set block to tell Redwood what layout you want to use for a given route, and never think about it again.

import { Router, Route, Set } from "@redwoodjs/router";
import BlogLayout from "src/layouts/BlogLayout/";

const Routes = () => {
  return (
    <Router>
      <Route path="/login" page={LoginPage} name="login" />
      <Set wrap={BlogLayout}>
        <Route path="/article/{id:Int}" page={ArticlePage} name="article" />
        <Route path="/" page={HomePage} name="home" />
      </Set>
      <Route notfound page={NotFoundPage} />
    </Router>
  );
};

export default Routes;

Notice that you don’t need to import the page components, as it is handled automatically. Why can’t we also auto-import the layouts though, as for example Nuxt 3 would? Beats me.

Another thing to note is the /article/{id:Int} part. Gone are the days when you always need to make sure to convert your integer ids if you get them from a path variable, as Redwood can convert them automatically for you, given you provide the necessary type hint.

Now’s a good time to take a look at SSG. The NotFoundPage probably doesn’t have any dynamic content, so we can generate it statically. Just add prerender, and you’re good.

const Routes = () => {
  return (
    <Router>
      ...
      <Route notfound page={NotFoundPage} prerender />
    </Router>
  );
};

export default Routes;

You can also tell Redwood that some of your pages require authentication. Unauthenticated users should be redirected if they try to request it.

import { Private, Router, Route, Set } from "@redwoodjs/router";
import BlogLayout from "src/layouts/BlogLayout/";

const Routes = () => {
  return (
    <Router>
      <Route path="/login" page={LoginPage} name="login" />
      <Private unauthenticated="login">
        <Set wrap={PostsLayout}>
          <Route
            path="/admin/posts/new"
            page={PostNewPostPage}
            name="newPost"
          />
          <Route
            path="/admin/posts/{id:Int}/edit"
            page={PostEditPostPage}
            name="editPost"
          />
        </Set>
      </Private>
      <Set wrap={BlogLayout}>
        <Route path="/article/{id:Int}" page={ArticlePage} name="article" />
        <Route path="/" page={HomePage} name="home" />
      </Set>
      <Route notfound page={NotFoundPage} />
    </Router>
  );
};

export default Routes;

Of course, you need to protect your mutations and queries, too. So make sure to append them with the pre-generated @requireAuth.

Another nice thing in Redwood is that you might not want to use a local auth strategy but rather outsource the problem of user management to an authentication provider, like Auth0 or Netlify-Identity. Redwood’s CLI can install the necessary packages and generate the required boilerplate automatically.

What looks strange, however, at least with local auth, is that the client makes several roundtrips to the server to get the token. More specifically, the server will be hit for each currentUser or isAuthenticated call.

Frontend goodies in Redwood

There are two things that I really loved about working with Redwood: Cells and Forms.

A cell is a component that fetches and manages its own data and state. You define the queries and mutations it will use, and then export a function for rendering the Loading, Empty, Failure, and Success states of the component. Of course, you can use the generator to create the necessary boilerplate for you.

A generated cell looks like this:

import type { ArticlesQuery } from "types/graphql";
import type { CellSuccessProps, CellFailureProps } from "@redwoodjs/web";

export const QUERY = gql`
  query ArticlesQuery {
    articles {
      id
    }
  }
`;

export const Loading = () => <div>Loading...</div>;

export const Empty = () => <div>Empty</div>;

export const Failure = ({ error }: CellFailureProps) => (
  <div style={{ color: "red" }}>Error: {error.message}</div>
);

export const Success = ({ articles }: CellSuccessProps<ArticlesQuery>) => {
  return (
    <ul>
      {articles.map((item) => {
        return <li key={item.id}>{JSON.stringify(item)}</li>;
      })}
    </ul>
  );
};

Then you just import and use it as you would any other component, for example, on a page.

import ArticlesCell from "src/components/ArticlesCell";

const HomePage = () => {
  return (
    <>
      <MetaTags title="Home" description="Home page" />
      <ArticlesCell />
    </>
  );
};

export default HomePage;

However! If you use SSG on pages with cells — or any dynamic content really —only their loading state will get pre-rendered, which is not much of a help. That’s right, no getStaticProps for you if you go with Redwood.

The other somewhat nice thing about Redwood is the way it eases form handling, though the way they frame it leaves a bit of a bad taste in my mouth. But first, the pretty part.

import { Form, FieldError, Label, TextField } from "@redwoodjs/forms";

const ContactPage = () => {
  return (
    <>
      <Form config={{ mode: "onBlur" }}>
        <Label name="email" errorClassName="error">
          Email
        </Label>
        <TextField
          name="email"
          validation={{
            required: true,
            pattern: {
              value: /^[^@]+@[^.]+\..+$/,
              message: "Please enter a valid email address",
            },
          }}
          errorClassName="error"
        />
        <FieldError name="email" className="error" />
      </Form>
    </>
  );
};

The TextField components validation attribute expects an object to be passed, with a pattern against which the provided input value can be validated.

The errorClassName makes it easy to set the style of the text field and its label in case the validation fails, e.g. turning it red. The validations message will be printed in the FieldError component. Finally, the config={{ mode: 'onBlur' }} tells the form to validate each field when the user leaves them.

The only thing that spoils the joy is the fact that this pattern is eerily similar to the one provided by Phoenix. Don’t get me wrong. It is perfectly fine, even virtuous, to copy what’s good in other frameworks. But I got used to paying homage when it’s due. Of course, it’s totally possible that the author of the tutorial did not know about the source of inspiration for this pattern. If that’s the case, let me know, and I’m happy to open a pull request to the docs, adding that short little sentence of courtesy.

But let’s continue and take a look at the whole working form.

import { MetaTags, useMutation } from "@redwoodjs/web";
import { toast, Toaster } from "@redwoodjs/web/toast";
import {
  FieldError,
  Form,
  FormError,
  Label,
  Submit,
  SubmitHandler,
  TextAreaField,
  TextField,
  useForm,
} from "@redwoodjs/forms";

import {
  CreateContactMutation,
  CreateContactMutationVariables,
} from "types/graphql";

const CREATE_CONTACT = gql`
  mutation CreateContactMutation($input: CreateContactInput!) {
    createContact(input: $input) {
      id
    }
  }
`;

interface FormValues {
  name: string;
  email: string;
  message: string;
}

const ContactPage = () => {
  const formMethods = useForm();

  const [create, { loading, error }] = useMutation<
    CreateContactMutation,
    CreateContactMutationVariables
  >(CREATE_CONTACT, {
    onCompleted: () => {
      toast.success("Thank you for your submission!");
      formMethods.reset();
    },
  });

  const onSubmit: SubmitHandler<FormValues> = (data) => {
    create({ variables: { input: data } });
  };

  return (
    <>
      <MetaTags title="Contact" description="Contact page" />

      <Toaster />
      <Form
        onSubmit={onSubmit}
        config={{ mode: "onBlur" }}
        error={error}
        formMethods={formMethods}
      >
        <FormError error={error} wrapperClassName="form-error" />

        <Label name="email" errorClassName="error">
          Email
        </Label>
        <TextField
          name="email"
          validation={{
            required: true,
            pattern: {
              value: /^[^@]+@[^.]+\..+$/,
              message: "Please enter a valid email address",
            },
          }}
          errorClassName="error"
        />
        <FieldError name="email" className="error" />

        <Submit disabled={loading}>Save</Submit>
      </Form>
    </>
  );
};

export default ContactPage;

Yeah, that’s quite a mouthful. But this whole thing is necessary if we want to properly handle submissions and errors returned from the server. We won’t dive deeper into it now, but if you’re interested, make sure to take a look at Redwood’s really nicely written and thorough tutorial.

Now compare this with how it would look like in Phoenix LiveView.

<div>
  <.form
    let={f}
    for={@changeset}
    id="contact-form"
    phx-target={@myself}
    phx-change="validate"
    phx-submit="save">

    <%= label f, :title %>
    <%= text_input f, :title %>
    <%= error_tag f, :title %>

    <div>
      <button type="submit" phx-disable-with="Saving...">Save</button>
    </div>
  </.form>
</div>

A lot easier to see through while providing almost the same functionality. Yes, you’d be right to call me out for comparing apples to oranges. One is a template language, while the other is JSX. Much of the logic in a LiveView happens in an elixir file instead of the template, while JSX is all about combining the logic with the view. However, I’d argue that an ideal full-stack framework should allow me to write the validation code once for inputs, then let me simply provide the slots in the view to insert the error messages into, and allow me to set up the conditional styles for invalid inputs and be done with it. This would provide a way to write cleaner code on the front-end, even when using JSX. You could say this is against the original philosophy of React, and my argument merely shows I have a beef with it. And you’d probably be right to do so. But this is an opinion article about opinionated frameworks, after all, so that’s that.

The people behind RedwoodJS

Credit, where credit is due.

Redwood was created by GitHub co-founder and former CEO Tom Preston-Werner, Peter Pistorius, David Price & Rob Cameron. Moreover, its core team currently consists of 23 people. So if you’re afraid to try out newish tools because you may never know when their sole maintainer gets tired of the struggles of working on a FOSS tool in their free time, you can rest assured: Redwood is here to stay.

Redwood: Honorable mentions

Redwood

• also comes bundled with Storybook,
• provides the must-have graphiql-like GraphQL Playground,
• provides accessibility features out of the box like the RouteAnnouncemnet SkipNavLink, SkipNavContent and RouteFocus components,
• of course it automatically splits your code by pages.

The last one is somewhat expected in 2022, while the accessibility features would deserve their own post in general. Still, this one is getting too long already, and we haven’t even mentioned the other contender yet.

Let’s see BlitzJS

Blitz is built on top of Next.js, and it is inspired by Ruby on Rails and provides a “Zero-API” data layer abstraction. No GraphQL, pays homage to predecessors… seems like we’re off to a good start. But does it live up to my high hopes? Sort of.

A troubled past

Compared to Redwood, Blitz’s tutorial and documentation are a lot less thorough and polished. It also lacks several convenience features: 

• It does not really autogenerate host-specific config files.
• Blitz cannot run a simple CLI command to set up auth providers.
• It does not provide accessibility helpers.
• Its code generator does not take into account the model when generating pages.

Blitz’s initial commit was made in February 2020, a bit more than half a year after Redwood’s in June 2019, and while Redwood has a sizable number of contributors, Blitz’s core team consists of merely 2-4 people. In light of all this, I think they deserve praise for their work.

But that’s not all. If you open up their docs, you’ll be greeted with a banner on top announcing a pivot.

While Blitz originally included Next.js and was built around it, Brandon Bayer and the other developers felt it was too limiting. Thus they forked it, which turned out to be a pretty misguided decision. It quickly became obvious that maintaining the fork would take a lot more effort than the team could invest.

All is not lost, however. The pivot aims to turn the initial value proposition “JavaScript on Rails with Next” into “JavaScript on Rails, bring your own Front-end Framework”. 

And I can’t tell you how relieved I am that this recreation of Rails won’t force me to use React. 

Don’t get me wrong. I love the inventiveness that React brought to the table. Front-end development has come a long way in the last nine years, thanks to React. Other frameworks like Vue and Svelte might lack behind in following the new concepts, but this also means they have more time to polish those ideas even further and provide better DevX. Or at least I find them a lot easier to work with without ever being afraid that my client-side code’s performance would grind to a standstill.

All in all, I find this turn of events a lucky blunder.

How to create a Blitz app

You’ll need to install Blitz globally (run yarn global add blitz or npm install -g blitz –legacy-peer-deps), before you create a Blitz app. That’s possibly my main woe when it comes to Blitz’s design, as this way, you cannot lock your project across all contributors to use a given Blitz CLI version and increment it when you see fit, as Blitz will automatically update itself from time to time.

Once blitz is installed, run

$ blitz new my-blitz-app

It will ask you 

• whether you want to use TS or JS, 
• if it should include a DB and Auth template (more on that later), 
• if you want to use npm, yarn or pnpm to install dependencies, 
• and if you want to use React Final Form or React Hook Form. 

Once you have answered all its questions, the CLI starts to download half of the internet, as it is customary. Grab something to drink, have a lunch, finish your workout session, or whatever you do to pass the time and when you’re done, you can fire up the server by running

$ blitz dev

And, of course, you’ll see the app running and the UI telling you to run

$ blitz generate all project name:string

But before we do that, let’s look around in the project directory.

my-blitz-app/
├── app/
├── db/
├── mailers/
├── node_modules/
├── public/
├── test/
├── integrations/
├── babel.config.js
├── blitz.config.ts
├── blitz-env.d.ts
├── jest.config.ts
├── package.json
├── README.md
├── tsconfig.json
├── types.ts
└── yarn.lock

Again, we can see the usual suspects: config files, node_modules, test, and the likes. The public directory — to no one’s surprise — is the place where you store your static assets. Test holds your test setup and utils. Integrations is for configuring your external services, like a payment provider or a mailer. Speaking of the mailer, that is where you can handle your mail-sending logic. Blitz generates a nice template with informative comments for you to get started, including a forgotten password email template.

As you’d probably guessed, the app and db directories are the ones where you have the bulk of your app-related code. Now’s the time to do as the generated landing page says and run blitz generate all project name:string.

Say yes, when it asks you if you want to migrate your database and give it a descriptive name like add project.

Now let’s look at the db directory.

my-blitz-app/
└── db/
    ├── db.sqlite
    ├── db.sqlite-journal
    ├── index.ts
    ├── migrations/
    │   ├── 20220610075814_initial_migration/
    │   │   └── migration.sql
    │   ├── 20220610092949_add_project/
    │   │   └── migration.sql
    │   └── migration_lock.toml
    ├── schema.prisma
    └── seeds.ts

The migrations directory is handled by Prisma, so it won’t surprise you if you’re already familiar with it. If not, I highly suggest trying it out on its own before you jump into using either Blitz or Redwood, as they heavily and transparently rely on it.

Just like in Redwood’s db dir, we have our schema.prisma, and our sqlite db, so we have something to start out with. But we also have a seeds.ts and index.ts. If you take a look at the index.ts file, it merely re-exports Prisma with some enhancements, while the seeds.ts file kind of speaks for itself.

Now’s the time to take a closer look at our schema.prisma.

// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

// --------------------------------------

model User {
  id             Int      @id @default(autoincrement())
  createdAt      DateTime @default(now())
  updatedAt      DateTime @updatedAt
  name           String?
  email          String   @unique
  hashedPassword String?
  role           String   @default("USER")

  tokens   Token[]
  sessions Session[]
}

model Session {
  id                 Int       @id @default(autoincrement())
  createdAt          DateTime  @default(now())
  updatedAt          DateTime  @updatedAt
  expiresAt          DateTime?
  handle             String    @unique
  hashedSessionToken String?
  antiCSRFToken      String?
  publicData         String?
  privateData        String?

  user   User? @relation(fields: [userId], references: [id])
  userId Int?
}

model Token {
  id          Int      @id @default(autoincrement())
  createdAt   DateTime @default(now())
  updatedAt   DateTime @updatedAt
  hashedToken String
  type        String
  // See note below about TokenType enum
  // type        TokenType
  expiresAt   DateTime
  sentTo      String

  user   User @relation(fields: [userId], references: [id])
  userId Int

  @@unique([hashedToken, type])
}

// NOTE: It's highly recommended to use an enum for the token type
//       but enums only work in Postgres.
//       See: https://blitzjs.com/docs/database-overview#switch-to-postgre-sql
// enum TokenType {
//   RESET_PASSWORD
// }

model Project {
  id        Int      @id @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  name      String
}

As you can see, Blitz starts out with models to be used with a fully functional User management. Of course, it also provides all the necessary code in the app scaffold, meaning that the least amount of logic is abstracted away, and you are free to modify it as you see fit.

Below all the user-related models, we can see the Project model we created with the CLI, with an automatically added id, createdAt, and updatedAt files. One of the things that I prefer in Blitz over Redwood is that its CLI mimics Phoenix, and you can really create everything from the command line end-to-end. 

This really makes it easy to move quickly, as less context switching happens between the code and the command line. Well, it would if it actually worked, as while you can generate the schema properly, the generated pages, mutations, and queries always use name: string, and disregard the entity type defined by the schema, unlike Redwood. There’s already an open pull request to fix this, but the Blitz team understandably has been focusing on getting v2.0 done instead of patching up the current stable branch.

That’s it for the db, let’s move on to the app directory.

my-blitz-app
└── app
    ├── api/
    ├── auth/
    ├── core/
    ├── pages/
    ├── projects/
    └── users/

The core directory contains Blitz goodies, like a predefined and parameterized Form (without Redwood’s or Phoenix’s niceties though), a useCurrentUser hook, and a Layouts directory, as Bliz made it easy to persist layouts between pages, which will be rendered completely unnecessary with the upcoming Next.js Layouts. This reinforces further that the decision to ditch the fork and pivot to a toolkit was probably a difficult but necessary decision.

The auth directory contains the fully functional authentication logic we talked about earlier, with all the necessary database mutations such as signup, login, logout, and forgotten password, with their corresponding pages and a signup and login form component. The getCurrentUser query got its own place in the users directory all by itself, which makes perfect sense.

And we got to the pages and projects directories, where all the action happens.

Blitz creates a directory to store database queries, mutations, input validations (using zod), and model-specific components like create and update forms in one place. You will need to fiddle around in these a lot, as you will need to update them according to your actual model. This is nicely laid out though in the tutorial… Be sure to read it, unlike I did when I first tried Blitz out.

my-blitz-app/
└── app/
    └── projects/
        ├── components/
        │   └── ProjectForm.tsx
        ├── mutations/
        │   ├── createProject.ts
        │   ├── deleteProject.ts
        │   └── updateProject.ts
        └── queries/
            ├── getProjects.ts
            └── getProject.ts

Whereas the pages directory won’t be of any surprise if you’re already familiar with Next.

my-blitz-app/
└── app/
    └── pages/
        ├── projects/
        │   ├── index.tsx
        │   ├── new.tsx
        │   ├── [projectId]/
        │   │   └── edit.tsx
        │   └── [projectId].tsx
        ├── 404.tsx
        ├── _app.tsx
        ├── _document.tsx
        ├── index.test.tsx
        └── index.tsx

A bit of explanation if you haven’t tried Next out yet: Blitz uses file-system-based routing just like Next. The pages directory is your root, and the index file is rendered when the path corresponding to a given directory is accessed. Thus when the root path is requested, pages/index.tsx will be rendered, accessing /projects will render pages/projects/index.tsx, /projects/new will render pages/projects/new.tsx and so on. 

If a filename is enclosed in []-s, it means that it corresponds to a route param. Thus /projects/15 will render pages/projects/[projectId].tsx. Unlike in Next, you access the param’s value within the page using the <code>useParam(name: string, type?: string)</code> hook. To access the query object, use the <code>useRouterQuery(name: string)</code>. To be honest, I never really understood why Next needs to mesh together the two.

When you generate pages using the CLI, all pages are protected by default. To make them public, simply delete the [PageComponent].authenticate = true line. This will throw an AuthenticationError if the user is not logged in anyway, so if you’d rather redirect unauthenticated users to your login page, you probably want to use [PageComponent].authenticate = {redirectTo: '/login'}.

In your queries and mutations, you can use the ctx context arguments value to call ctx.session.$authorize or resolver.authorize in a pipeline to secure your data.

Finally, if you still need a proper http API, you can create Express-style handler functions, using the same file-system routing as for your pages.

A possible bright future

While Blitz had a troubled past, it might have a bright future. It is still definitely in the making and not ready for widespread adoption. The idea of creating a framework agnostic full-stack JavaScript toolkit is a versatile concept. This strong concept is further reinforced by the good starting point, which is the current stable version of Blitz. I’m looking further to see how the toolkit will evolve over time.

Redwood vs. Blitz: Comparison and Conclusion

I set out to see whether we have a Rails, or even better, Phoenix equivalent in JavaScript. Let’s see how they measured up.

1. CLI code generator

Redwood’s CLI gets the checkmark on this one, as it is versatile, and does what it needs to do. The only small drawback is that the model has to be written in file first, and cannot be generated.

Blitz’s CLI is still in the making, but that’s true about Blitz in general, so it’s not fair to judge it by what’s ready, but only by what it will be. In that sense, Blitz would win if it was fully functional (or will when it will be), as it can really generate pages end-to-end.

Verdict: Tie

2. A powerful ORM

That’s a short one. Both use Prisma, which is a powerful enough ORM.

Verdict: Tie

3. Server side rendered but interactive pages

Well, in today’s ecosystem, that might be wishful thinking. Even in Next, SSR is something you should avoid, at least until we’ll have Server Components in React.

But which one mimics this behavior the best?

Redwood does not try to look like a Rails replacement. It has clear boundaries demarcated by yarn workspaces between front-end and back-end . It definitely provides nice conventions and — to keep it charitable — nicely reinvented the right parts of Phoenix’s form handling. However, strictly relying on GraphQL feels a bit overkill. For small apps that we start out with anyway when opting to use a full-stack framework, it definitely feels awkward.

Redwood is also React exclusive, so if you prefer using Vue, Svelte or Solid, then you have to wait until someone reimplements Redwood for your favorite framework.

Blitz follows the Rails way, but the controller layer is a bit more abstract. This is understandable, though, as using Next’s file-system-based routing, a lot of things that made sense for Rails do not make sense for Blitz. And in general, it feels more natural than using GraphQL for everything. In the meantime, becoming framework agnostic makes it even more versatile than Redwood.

Moreover, Blitz is on its way to becoming framework agnostic, so even if you’d never touch React, you’ll probably be able to see its benefits in the near future.

But to honor the original criterion: Redwood provides client-side rendering and SSG (kind of), while Blitz provides SSR on top of the previous two.

Verdict: Die-hard GraphQL fans will probably want to stick with Redwood. But according to my criteria, Blitz hands down wins this one.

4. API

Blitz auto generates an API for data access that you can use if you want to, but you can explicitly write handler functions too. A little bit awkward, but the possibility is there.

Redwood maintains a hard separation between front-end and back-end, so it is trivial that you have an API, to begin with. Even if it’s a GraphQL API, that might just be way too much to engineer for your needs.

Verdict: Tie (TBH, I feel like they both suck at this the same amount.)

Bye now!

In summary, Redwood is a production-ready, React+GraphQL-based full-stack JavaScript framework made for the edge. It does not follow the patterns laid down by Rails at all, except for being highly opinionated. It is a great tool to use if you share its sentiment, but my opinion greatly differs from Redwood’s on what makes development effective and enjoyable.

Blitz, on the other hand, follows in the footsteps of Rails and Next, and is becoming a framework agnostic, full-stack toolkit that eliminates the need for an API layer.

I hope you found this comparison helpful. Leave a comment if you agree with my conclusion and share my love for Blitz. If you don’t, argue with the enlightened ones… they say controversy boosts visitor numbers.

Usually, when devs set up a CI/CD pipeline for an application hosted on KubernetesKubernetes (often abbreviated as K8s) offers a framework to run distributed systems efficiently. It's a platform that helps managing containerized workloads and services, and even takes care of scaling. Google open-sourced it in 2014., they handle both the CI and CD parts in one task runner, such as CircleCI or Travis CI. These services offer push-based updates to your deployments, which means that credentials for the code repo and the deployment target must be stored with these services. This method can be problematic if the service gets compromised, e.g. as it happened to CodeShip.

Even using services such as GitLab CI and GitHub Actions requires that credentials for accessing your cluster be stored with them. If you’re employing GitOps, to take advantage of using the usual Push to repo -> Review Code -> Merge Code sequence for managing your infrastructure configuration as well, this would also mean access to your whole infrastructure.

[elementor-template id="3483"]

Luckily there are tools to help us with these issues. Two of the most known are Argo CD and Flux. They allow credentials to be stored within your Kubernetes cluster, where you have more control over their security. They also offer pull-based deployment with drift detection. Both of these tools solve the same issues, but tackle them from different angles.

Here, we’ll take a deeper look at Argo CD out of the two.

What is Argo CD

Argo CD is a continuous deployment tool that you can install into your Kubernetes cluster. It can pull the latest code from a git repository and deploy it into the cluster – as opposed to external CD services, deployments are pull-based. You can manage updates for both your application and infrastructure configuration with Argo CD. Advantages of such a setup include being able to use credentials from the cluster itself for deployments, which can be stored in secrets or a vault.

Preparation

To try out Argo CD, we’ve also prepared a test project that we’ll deploy to Kubernetes hosted on DigitalOcean. You can grab the example project from our GitLab repository here: https://gitlab.com/risingstack-org/argocd-demo/

Forking the repo will allow you to make changes for yourself, and it can be set up later in Argo CD as the deployment source.

Get doctl from here:

https://docs.digitalocean.com/reference/doctl/how-to/install/

Or, if you’re using a mac, from Homebrew:

brew install doctl

You can use any Kubernetes provider for this tutorial. The two requirements are having a Docker repository and a Kubernetes cluster with access to it. For this tutorial, we chose to go with DigitalOcean for the simplicity of its setup, but most other platforms should work just fine.

We’ll focus on using the web UI for the majority of the process, but you can also opt to use the `doctl` cli tool if you wish. `doctl` can mostly replace `kubectl` as well. `doctl` will only be needed to push our built docker image to the repo that our deployment will have access to.

Helm is a templating engine for Kubernetes. It allows us to define values separately from the structure of the yaml files, which can help with access control and managing multiple environments using the same template.

You can grab Helm here: https://github.com/helm/helm/releases

Or via Homebrew for mac users:

brew install helm

Download the latest Argo CD version from https://github.com/argoproj/argo-cd/releases/latest

If you’re using a mac, you can grab the cli tools from Homebrew:

brew install argocd

DigitalOcean Setup

After logging in, first, create a cluster using the “Create” button on the top right, and selecting Kubernetes. For the purposes of this demo, we can just go with the smallest cluster with no additional nodes. Be sure to choose a data center close to you.

Preparing the demo app

You can find the demo app in the node-app folder in the repo you forked. Use this folder for the following steps to build and push the docker image to the GitLab registry:

docker login registry.gitlab.com

docker build . -t registry.gitlab.com/<substiture repo name here>/demo-app-1

docker push registry.gitlab.com/<substiture repo name here>/demo-app-1

GitLab offers a free image registry with every git repo – even free tier ones. You can use these to store your built image, but be aware that the registry inherits the privacy setting of the git repo, you can’t change them separately.

Once the image is ready, be sure to update the values.yaml file with the correct image url and use helm to generate the resources.yaml file. You can then deploy everything using kubectl:

helm template -f "./helm/demo-app/values.yaml" "./helm/demo-app" > "./helm/demo-app/resources/resources.yaml"

kubectl apply -f helm/demo-app/resources/resources.yaml

The only purpose of these demo-app resources’ is to showcase the ArgoCD UI capabilities, that’s why it also contains an Ingress resource as a plus.

Install Argo CD into the cluster

Argo CD provides a yaml file that installs everything you’ll need and it’s available online. The most important thing here is to make sure that you install it into the `argocd` namespace, otherwise, you’ll run into some errors later and Argo CD will not be usable.

kubectl create namespace argocd

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

From here, you can use Kubernetes port-forwarding to access the UI of Argo CD:

kubectl -n argocd port-forward svc/argocd-server 8080:443

This will expose the service on localhost:8080 – we will use the UI to set up the connection to GitLab, but it could also be done via the command line tool.

Argo CD setup

To log in on the UI, use `admin` as username, and the password retrieved by this command:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Once you’re logged in, connect your fork of the demo app repo from the Repositories inside the Settings menu on the left side. Here, we can choose between ssh and https authentication – for this demo, we’ll use https, but for ssh, you’d only need to set up a key pair for use.

Create an API key on GitLab and use it in place of a password alongside your username to connect the repo. An API key allows for some measure of access control as opposed to using your account password.

After successfully connecting the repository, the only thing left is to set up an Application, which will take care of synchronizing the state of our deployment with that described in the GitLab repo.

You’ll need to choose a branch or a tag to use to monitor. Let’s choose the master branch for now – it should contain the latest stable code anyway. Setting the sync policy to automatic allows for automatic deployments when the git repo is updated, and also provides automatic pruning and self-healing capabilities.

Be sure to set the destination cluster to the one available in the dropdown and use the `demo` namespace. If everything is set correctly, Argo CD should now start syncing the deployment state.

Features of Argo CD

From the application view, you can now see the different parts that comprise our demo application.

Clicking on any of these parts allows for checking the diff of the deployed config, and the one checked into git, as well as the yaml files themselves separately. The diff should be empty for now, but we’ll see it in action once we make some changes or if you disable automatic syncing.

You also have access to the logs from the pods here, which can be quite useful – logs are not retained between different pod instances, which means that they are lost on the deletion of a pod, however.

It is also possible to handle rollbacks from here, clicking on the “History and Rollback” button. Here, you can see all the different versions that have been deployed to our cluster by commit. 

You can re-deploy any of them using the … menu on the top right, and selecting “Redeploy” – this feature needs automatic deployment to be turned off. However, you’ll be prompted to do so here.

These should cover the most important parts of the UI and what is available in Argo CD. Next up, we’ll take a look at how the deployment update happens when code changes on GitLab.

Updating the deployment

With the setup done, any changes you make to the configuration that you push to the master branch should be reflected on the deployment shortly after.

A very simple way to check out the updating process is to bump up the `replicaCount` in values.yaml to 2 (or more), and run the helm command again to generate the resources.yaml. 

Then, commit and push to master and monitor the update process on the Argo CD UI.

You should see a new event in the demo-app events, with the reason `ScalingReplicaSet`.

You can double-check the result using kubectl, where you should now see two instances of the demo-app running:

kubectl -n demo get pod

There is another branch prepared in the repo, called second-app, which has another app that you can deploy, so you can see some more of the update process and diffs. It is quite similar to how the previous deployment works.

First, you’ll need to merge the second-app branch into master – this will allow the changes to be automatically deployed, as we set it up already. Then, from the node-app-2 folder, build and push the docker image. Make sure to have a different version tag for it, so we can use the same repo!

docker build . -t registry.gitlab.com/<substitute repo name here>/demo-app-2

docker push registry.gitlab.com/<substitute repo name here>/demo-app-2

You can set deployments to manual for this step, to be able to take a better look at the diff before the actual update happens. You can do this from the sync settings part of `App details`.

Generate the updated resources file afterwards, then commit and push it to git to trigger the update in Argo CD:

helm template -f "./helm/demo-app/values.yaml" "./helm/demo-app" > "./helm/demo-app/resources/resources.yaml"

This should result in a diff appearing `App details` -> `Diff` for you to check out. You can either deploy it manually or just turn auto-deploy back.

ArgoCD safeguards you from those resource changes that are drifting from the latest source-controlled version of your code. Let’s try to manually scale up the deployment to 5 instances:

Get the name of the replica set:

kubectl -n demo get rs

Scale it to 5 instances:

kubectl -n demo scale --replicas=5 rs/demo-app-<number>

If you are quick enough, you can catch the changes applied on the ArgoCD Application Visualization as it tries to add those instances. However, ArgoCD will prevent this change, because it would drift from the source controlled version of the deployment. It also scales the deployment down to the defined value in the latest commit (in my example it was set to 3). 

The downscale event can be found under the `demo-app` deployment events, as shown below:

From here, you can experiment with whatever changes you’d like!

Finishing our ArgoCD Kubernetes Tutorial

This was our quick introduction to using ArgoCD, which can make your GitOps workflow safer and more convenient.

Stay tuned, as we’re planning to take a look at the other heavy-hitter next time: Flux.

This article was written by Janos Kubisch, senior engineer at RisingStack.