{"componentChunkName":"component---src-templates-content-template-js","path":"/en/part7/miscellaneous","result":{"data":{"markdownRemark":{"html":"
\n

Class Components

\n

During the course, we have only used React components having been defined as JavaScript functions. This was not possible without the hook functionality that came with version 16.8 of React. Before, when defining a component that uses state, one had to define it using JavaScript's Class syntax.

\n

It is beneficial to at least be familiar with Class Components to some extent since the world contains a lot of old React code, which will probably never be completely rewritten using the updated syntax.

\n

Let's get to know the main features of Class Components by producing yet another very familiar anecdote application. We store the anecdotes in the file db.json using json-server. The contents of the file are taken from here.

\n

The initial version of the Class Component looks like this

\n
import React from 'react'\n\nclass App extends React.Component {\n  constructor(props) {\n    super(props)\n  }\n\n  render() {\n    return (\n      <div>\n        <h1>anecdote of the day</h1>\n      </div>\n    )\n  }\n}\n\nexport default App
\n

The component now has a constructor, in which nothing happens at the moment, and contains the method render. As one might guess, render defines how and what is rendered to the screen.

\n

Let's define a state for the list of anecdotes and the currently-visible anecdote. In contrast to when using the useState hook, Class Components only contain one state. So if the state is made up of multiple \"parts\", they should be stored as properties of the state. The state is initialized in the constructor:

\n
class App extends React.Component {\n  constructor(props) {\n    super(props)\n\n    this.state = {      anecdotes: [],      current: 0    }  }\n\n  render() {\n    if (this.state.anecdotes.length === 0) {      return <div>no anecdotes...</div>    }\n    return (\n      <div>\n        <h1>anecdote of the day</h1>\n        <div>          {this.state.anecdotes[this.state.current].content}        </div>        <button>next</button>      </div>\n    )\n  }\n}
\n

The component state is in the instance variable this.state. The state is an object having two properties. this.state.anecdotes is the list of anecdotes and this.state.current is the index of the currently-shown anecdote.

\n

In Functional components, the right place for fetching data from a server is inside an effect hook, which is executed when a component renders or less frequently if necessary, e.g. only in combination with the first render.

\n

The lifecycle methods of Class Components offer corresponding functionality. The correct place to trigger the fetching of data from a server is inside the lifecycle method componentDidMount, which is executed once right after the first time a component renders:

\n
class App extends React.Component {\n  constructor(props) {\n    super(props)\n\n    this.state = {\n      anecdotes: [],\n      current: 0\n    }\n  }\n\n  componentDidMount = () => {    axios.get('http://localhost:3001/anecdotes').then(response => {      this.setState({ anecdotes: response.data })    })  }\n  // ...\n}
\n

The callback function of the HTTP request updates the component state using the method setState. The method only touches the keys that have been defined in the object passed to the method as an argument. The value for the key current remains unchanged.

\n

Calling the method setState always triggers the rerender of the Class Component, i.e. calling the method render.

\n

We'll finish off the component with the ability to change the shown anecdote. The following is the code for the entire component with the addition highlighted:

\n
class App extends React.Component {\n  constructor(props) {\n    super(props)\n\n    this.state = {\n      anecdotes: [],\n      current: 0\n    }\n  }\n\n  componentDidMount = () => {\n    axios.get('http://localhost:3001/anecdotes').then(response => {\n      this.setState({ anecdotes: response.data })\n    })\n  }\n\n  handleClick = () => {    const current = Math.floor(      Math.random() * this.state.anecdotes.length    )    this.setState({ current })  }\n  render() {\n    if (this.state.anecdotes.length === 0 ) {\n      return <div>no anecdotes...</div>\n    }\n\n    return (\n      <div>\n        <h1>anecdote of the day</h1>\n        <div>{this.state.anecdotes[this.state.current].content}</div>\n        <button onClick={this.handleClick}>next</button>      </div>\n    )\n  }\n}
\n

For comparison, here is the same application as a Functional component:

\n
const App = () => {\n  const [anecdotes, setAnecdotes] = useState([])\n  const [current, setCurrent] = useState(0)\n\n  useEffect(() =>{\n    axios.get('http://localhost:3001/anecdotes').then(response => {\n      setAnecdotes(response.data)\n    })\n  },[])\n\n  const handleClick = () => {\n    setCurrent(Math.round(Math.random() * (anecdotes.length - 1)))\n  }\n\n  if (anecdotes.length === 0) {\n    return <div>no anecdotes...</div>\n  }\n\n  return (\n    <div>\n      <h1>anecdote of the day</h1>\n      <div>{anecdotes[current].content}</div>\n      <button onClick={handleClick}>next</button>\n    </div>\n  )\n}
\n

In the case of our example, the differences were minor. The biggest difference between Functional components and Class components is mainly that the state of a Class component is a single object, and that the state is updated using the method setState, while in Functional components the state can consist of multiple different variables, with all of them having their own update function.

\n

In 2026, Class Components are largely a historical artifact. All modern React development uses Functional components with hooks, and there is no rational reason to reach for a Class component when writing new code. The React documentation itself treats Class components as a legacy API.

\n

Error boundary

\n

Even though Class Components are largely obsolete, there is one situation where you still cannot avoid them: error boundaries. An error boundary is a component that catches JavaScript errors anywhere in its child component tree and displays a fallback UI instead of crashing the whole application. As of 2026, React has not yet introduced a hook-based alternative for this, so error boundaries must still be implemented as Class components.

\n

An error boundary looks like this:

\n
import React from 'react'\n\nclass ErrorBoundary extends React.Component {\n  constructor(props) {\n    super(props)\n    this.state = { hasError: false, error: null }\n  }\n\n  static getDerivedStateFromError(error) {\n    return { hasError: true, error }\n  }\n\n  componentDidCatch(error, info) {\n    console.error('ErrorBoundary caught an error', error, info)\n  }\n\n  render() {\n    if (this.state.hasError) {\n      return (\n        <div>\n          <h2>Something went wrong.</h2>\n          <p>{this.state.error.message}</p>\n          <button onClick={() => this.setState({ hasError: false, error: null })}>\n            try again\n          </button>\n        </div>\n      )\n    }\n\n    return this.props.children\n  }\n}\n\nexport default ErrorBoundary
\n

The two key lifecycle methods are getDerivedStateFromError, which updates state so the next render shows the fallback UI, and componentDidCatch, which is a good place to log the error to an error reporting service.

\n

You can wrap any part of your component tree with an error boundary to contain failures to that subtree:

\n
const App = () => {\n  return (\n    <div>\n      <ErrorBoundary>\n        <Notes />\n      </ErrorBoundary>\n      <ErrorBoundary>\n        <Persons />\n      </ErrorBoundary>\n    </div>\n  )\n}
\n

If Notes throws an error, only that section shows the fallback. Persons continues to work normally.

\n

Because this is the one remaining use case for Class components, many projects use the react-error-boundary library, which wraps the class-based machinery behind a convenient Functional component API so you never have to write a Class component yourself.

\n

Frontend and backend in the same repository

\n

During the course, we have created the frontend and backend into separate repositories. This is a very typical approach. However, we did the deployment by copying the bundled frontend code into the backend repository. A possibly better approach would have been to deploy the frontend code separately.

\n

Sometimes the entire application is put into a single repository. A common and clean way to do this with a modern stack is to keep the Vite frontend in a client directory and the Express backend in a server directory, each with their own package.json. The root of the repository gets a third package.json that acts as a convenience wrapper with scripts to run both together.

\n

A minimal layout of such a repository looks like this:

\n
app/\n  package.json        (root, scripts only)\n  client/\n    package.json      (Vite + React)\n    vite.config.js\n    src/\n      App.jsx\n  server/\n    package.json      (Express)\n    index.js
\n

The Express server in server/index.js serves the API and, in production, also serves the built frontend from the client/dist directory:

\n
const express = require('express')\nconst path = require('path')\n\nconst app = express()\n\napp.use(express.json())\n\napp.get('/api/ping', (req, res) => {\n  res.json({ message: 'pong', time: new Date().toISOString() })\n})\n\n// serve the built Vite frontend in production\nif (process.env.NODE_ENV === 'production') {\n  app.use(express.static(path.join(__dirname, '../client/dist')))\n  app.get('/*splat', (req, res) => {\n    res.sendFile(path.join(__dirname, '../client/dist/index.html'))\n  })\n}\n\nconst PORT = process.env.PORT || 3001\napp.listen(PORT, () => console.log(`server running on port ${PORT}`))
\n

During development, the Vite dev server runs on its own port and needs to forward API requests to Express. This is configured in client/vite.config.js:

\n
import { defineConfig } from 'vite'\nimport react from '@vitejs/plugin-react'\n\nexport default defineConfig({\n  plugins: [react()],\n  server: {\n    proxy: {\n      '/api': 'http://localhost:3001',\n    },\n  },\n})
\n

With the proxy in place, a frontend fetch to /api/ping is automatically forwarded to the Express server during development, so you never have to hard-code the backend URL.

\n

The root package.json ties everything together with a couple of scripts:

\n
{\n  \"scripts\": {\n    \"dev\": \"concurrently \\\"npm run dev --prefix server\\\" \\\"npm run dev --prefix client\\\"\",\n    \"build\": \"npm run build --prefix client\",\n    \"start\": \"NODE_ENV=production npm start --prefix server\"\n  },\n  \"devDependencies\": {\n    \"concurrently\": \"^8.0.0\"\n  }\n}
\n

There are couple things interesting here.

\n

The dev script uses concurrently, a small utility that runs multiple commands at the same time and merges their output into a single terminal stream. Without it you would have to open two separate terminals, one for the backend and one for the frontend.

\n

The --prefix flag tells npm which subdirectory to treat as the working directory for that command, so npm run dev --prefix server is equivalent to cd server && npm run dev.

\n

Running npm run dev from the root therefore starts both the Vite dev server and Express in parallel with a single command. In this mode, Vite serves the frontend with hot module replacement: when you edit a React component, the browser updates instantly without a full page reload. The Express server runs separately and the Vite proxy forwards /api requests to it.

\n

Running npm run build compiles the frontend into the client/dist directory. After that, npm start sets NODE_ENV=production and starts Express, which picks up the static files from client/dist and serves both the API and the frontend from a single port. This is the setup you would use when deploying to a server.

\n

Because each part of the project has its own package.json, you need to be explicit about which one you are targeting when installing new packages. The same --prefix flag works for npm install as well:

\n
npm install axios --prefix client     # add to the frontend\nnpm install mongoose --prefix server  # add to the backend
\n

Alternatively, you can simply cd into the directory and run npm install from there as you normally would.

\n

Organization of code in React application

\n

In most applications during this course, we followed the convention of placing components in a components directory, hooks in hooks, and server communication code in services. For the BlogList app that might look like this:

\n
src/\n  App.jsx\n  components/\n    Blog.jsx\n    BlogList.jsx\n    LoginForm.jsx\n    Notification.jsx\n  hooks/\n    useField.js\n  services/\n    blogs.js\n    users.js\n  stores/\n    blogStore.js\n    notificationStore.js
\n

This flat, type-based grouping works well for small applications.

\n

When the app uses routing, it is common to add a pages directory (sometimes called views) for the top-level route components, keeping reusable UI components in components. This convention is used by frameworks such as Next.js and is described in the React FAQ on file structure:

\n
src/\n  App.jsx\n  pages/\n    HomePage.jsx\n    BlogPage.jsx\n    UserPage.jsx\n  components/\n    Blog.jsx\n    BlogList.jsx\n    LoginForm.jsx\n    Notification.jsx\n  hooks/\n    useField.js\n  services/\n    blogs.js\n    users.js\n  stores/\n    blogStore.js\n    notificationStore.js
\n

As the codebase grows further, however, a change to a single feature may still touch files scattered across every directory, and both components and pages can become hard to navigate.

\n

A common response to this is to group files by feature instead. The Feature-Sliced Design methodology formalises this approach, and the bulletproof-react project is a widely-referenced example of applying it in practice:

\n
src/\n  App.jsx\n  features/\n    blogs/\n      Blog.jsx\n      BlogList.jsx\n      blogService.js\n      blogStore.js\n    users/\n      UserList.jsx\n      userService.js\n    notifications/\n      Notification.jsx\n      notificationStore.js\n  hooks/\n    useField.js
\n

Everything related to blogs lives together, so adding or changing a feature means working in one place rather than several. There is no single correct way to organize a larger project, and the right choice depends on the size and nature of the application.

\n

Changes on the server

\n

The applications we build during this course fetch data from the server when the page loads and after user actions, but they have no way of learning about changes made by other users. If a fellow user adds a new blog post, our frontend simply does not know about it until the page is refreshed. How can we keep the UI in sync with a server that changes independently?

\n

The simplest approach is polling: the frontend repeatedly asks the server for fresh data at a fixed interval, for example using setInterval. Polling is easy to implement but wasteful, because most requests return nothing new.

\n

A cleaner alternative is WebSockets, which open a persistent two-way connection between the browser and the server. The server can then push updates to connected clients the moment something changes, without the client having to ask. WebSockets are now supported by all modern browsers.

\n

Working directly with the WebSocket API can be cumbersome. The Socket.io library wraps it with a higher-level API and adds automatic reconnection and other conveniences.

\n

In part 8 we look at GraphQL, which includes a subscription mechanism that lets the server notify clients about data changes in a structured way.

\n

React/node-application security

\n

So far during the course, we have not touched on information security much. We do not have much time for this now either, but fortunately, University of Helsinki has a MOOC course Securing Software for this important topic.

\n

We will, however, take a look at some things specific to this course.

\n

The Open Web Application Security Project, otherwise known as OWASP, publishes an annual list of the most common security risks in Web applications. The most recent list can be found here. The same risks can be found from one year to another.

\n

At the top of the list, we find injection, which means that e.g. text sent using a form in an application is interpreted completely differently than the software developer had intended. The most famous type of injection is probably SQL injection.

\n

For example, imagine that the following SQL query is executed in a vulnerable application:

\n
let query = \"SELECT * FROM Users WHERE name = '\" + userName + \"';\"
\n

Now let's assume that a malicious user Arto Hellas would define their name as

\n
Arto Hell-as'; DROP TABLE Users; --
\n

so that the name would contain a single quote ', which is the beginning and end character of a SQL string. As a result of this, two SQL operations would be executed, the second of which would destroy the database table Users:

\n
SELECT * FROM Users WHERE name = 'Arto Hell-as'; DROP TABLE Users; --'
\n

SQL injections are prevented using parameterized queries. With them, user input isn't mixed with the SQL query, but the database itself inserts the input values at placeholders in the query (usually ?):

\n
execute(\"SELECT * FROM Users WHERE name = ?\", [userName])
\n

Injection attacks are also possible in NoSQL databases. However, mongoose prevents them by sanitizing the queries. More on the topic can be found e.g. here.

\n

Cross-site scripting (XSS) is an attack where it is possible to inject malicious JavaScript code into a legitimate web application. The malicious code would then be executed in the browser of the victim. If we try to inject the following into e.g. the notes application:

\n
<script>\n  alert('Evil XSS attack')\n</script>
\n

the code is not executed, but is only rendered as 'text' on the page:

\n\"browser\n

since React takes care of sanitizing data in variables. Some versions of React have been vulnerable to XSS attacks. The security holes have of course been patched, but there is no guarantee that there couldn't be any more.

\n

One needs to remain vigilant when using libraries; if there are security updates to those libraries, it is advisable to update those libraries in one's applications. Security updates for Express are found in the library's documentation and the ones for Node are found in this blog.

\n

You can check how up-to-date your dependencies are using the command

\n
npm outdated --depth 0
\n

The one-year-old project that is used in part 9 of this course already has quite a few outdated dependencies:

\n\"npm\n

The dependencies can be brought up to date by updating the file package.json. The best way to do that is by using a tool called npm-check-updates. It can be installed globally by running the command:

\n
npm install -g npm-check-updates
\n

Using this tool, the up-to-dateness of dependencies is checked in the following way:

\n
$ npm-check-updates\nChecking ...\\my-app\\package.json\n[====================] 11/11 100%\n\n @testing-library/react       ^14.0.0  →  ^15.0.0\n @testing-library/user-event  ^14.4.3  →  ^14.5.2\n react                        ^18.2.0  →  ^19.0.0\n vite                          ^5.0.0  →   ^6.0.0\n\nRun ncu -u to upgrade package.json
\n

The file package.json is brought up to date by running the command ncu -u.

\n
$ ncu -u\nUpgrading ...\\my-app\\package.json\n[====================] 11/11 100%\n\n @testing-library/react       ^14.0.0  →  ^15.0.0\n @testing-library/user-event  ^14.4.3  →  ^14.5.2\n react                        ^18.2.0  →  ^19.0.0\n vite                          ^5.0.0  →   ^6.0.0\n\nRun npm install to install new versions.
\n

Then it is time to update the dependencies by running the command npm install. However, old versions of the dependencies are not necessarily a security risk.

\n

The npm audit command can be used to check the security of dependencies. It compares the version numbers of the dependencies in your application to a list of the version numbers of dependencies containing known security threats in a centralized error database.

\n

Running npm audit on the same project, it prints a long list of complaints and suggested fixes.\nBelow is a part of the report:

\n
$ patientor npm audit\n\n... many lines removed ...\n\nurl-parse  <1.5.2\nSeverity: moderate\nOpen redirect in url-parse - https://github.com/advisories/GHSA-hh27-ffr2-f2jc\nfix available via `npm audit fix`\nnode_modules/url-parse\n\nws  6.0.0 - 6.2.1 || 7.0.0 - 7.4.5\nSeverity: moderate\nReDoS in Sec-Websocket-Protocol header - https://github.com/advisories/GHSA-6fc8-4gx4-v693\nReDoS in Sec-Websocket-Protocol header - https://github.com/advisories/GHSA-6fc8-4gx4-v693\nfix available via `npm audit fix`\nnode_modules/webpack-dev-server/node_modules/ws\nnode_modules/ws\n\n120 vulnerabilities (102 moderate, 16 high, 2 critical)\n\nTo address issues that do not require attention, run:\n  npm audit fix\n\nTo address all issues (including breaking changes), run:\n  npm audit fix --force
\n

After only one year, the code is full of small security threats. Luckily, there are only 2 critical threats. Let's run npm audit fix as the report suggests:

\n
$ npm audit fix\n\n+ mongoose@5.9.1\nadded 19 packages from 8 contributors, removed 8 packages and updated 15 packages in 7.325s\nfixed 354 of 416 vulnerabilities in 20047 scanned packages\n  1 package update for 62 vulns involved breaking changes\n  (use `npm audit fix --force` to install breaking changes; or refer to `npm audit` for steps to fix these manually)
\n

62 threats remain because, by default, audit fix does not update dependencies if their major version number has increased. Updating these dependencies could lead to the whole application breaking down.

\n

The source for the critical bug is the library immer

\n
immer  <9.0.6\nSeverity: critical\nPrototype Pollution in immer - https://github.com/advisories/GHSA-33f9-j839-rf8h\nfix available via `npm audit fix --force`\nWill install react-scripts@5.0.0, which is a breaking change
\n

Running npm audit fix --force would upgrade the library version but would also upgrade the library react-scripts and that would potentially break down the development environment. So we will leave the library upgrades for later...

\n

One of the threats mentioned in the list from OWASP is Broken Authentication and the related Broken Access Control. The token-based authentication we have been using is fairly robust if the application is being used on the traffic-encrypting HTTPS protocol. When implementing access control, one should e.g. remember to not only check a user's identity in the browser but also on the server. Bad security would be to prevent some actions to be taken only by hiding the execution options in the code of the browser.

\n

On Mozilla's MDN, there is a very good Website security guide, which brings up this very important topic:

\n\"screenshot\n

The documentation for Express includes a section on security: Production Best Practices: Security, which is worth a read. It is also recommended to add a library called Helmet to the backend. It includes a set of middleware that eliminates some security vulnerabilities in Express applications.

\n

Using the ESlint security-plugin is also worth doing.

\n

Current trends

\n

Finally, let's take a look at some technology of tomorrow (or, actually, already today), and the directions in which Web development is heading.

\n

Typed versions of JavaScript

\n

The dynamic typing of JavaScript can lead to subtle bugs that are only discovered at runtime. In part 5, we touched on PropTypes as a way to add runtime type checks to component props, but PropTypes have largely fallen out of use as the ecosystem has moved toward static type checking.

\n

TypeScript, developed by Microsoft, has become the de facto standard for typed JavaScript. It catches type errors at compile time rather than at runtime, provides excellent editor tooling, and is now used by the majority of new React projects. TypeScript is covered in part 9.

\n

Server-side rendering and React Server Components

\n

React components do not have to run in the browser. They can also be rendered on the server, which sends ready-made HTML to the client instead of a blank page that JavaScript must fill in. This server-side rendering (SSR) improves perceived load time and is important for Search Engine Optimization (SEO), since search engine crawlers see fully rendered content without having to execute JavaScript.

\n

The more recent and significant development is React Server Components (RSC), introduced in React 18 and now a core part of the React architecture. A Server Component runs exclusively on the server and is never sent to the browser as JavaScript. It can read directly from a database or file system, keep secrets out of the client bundle, and stream its output to the browser. The browser receives these components as rendered data, not as executable code. Client Components, annotated with 'use client', still run in the browser and handle interactivity as before. In an RSC application most components are Server Components by default, with Client Components used only where user interaction is needed.

\n

Next.js has become the standard framework for building React applications that require server-side behaviour. Its App Router (introduced in Next.js 13) is built around React Server Components and provides file-based routing, nested layouts, server actions for mutating data, and built-in support for static generation and incremental static regeneration. In 2026, Next.js is the first choice for any React project where SSR, SEO, or full-stack capabilities matter.

\n

Microservice architecture

\n

During this course, we have only scratched the surface of the server end of things. In our applications, we had a monolithic backend, meaning one application making up a whole and running on a single server, serving only a few API endpoints.

\n

As the application grows, the monolithic backend approach starts turning problematic both in terms of performance and maintainability.

\n

A microservice architecture (microservices) is a way of composing the backend of an application from many separate, independent services, which communicate with each other over the network. An individual microservice's purpose is to take care of a particular logical functional whole. In a pure microservice architecture, the services do not use a shared database.

\n

For example, the bloglist application could consist of two services: one handling the user and another taking care of the blogs. The responsibility of the user service would be user registration and user authentication, while the blog service would take care of operations related to the blogs.

\n

The image below visualizes the difference between the structure of an application based on a microservice architecture and one based on a more traditional monolithic structure:

\n\"microservices\n

The role of the frontend (enclosed by a square in the picture) does not differ much between the two models. There is often a so-called API gateway between the microservices and the frontend, which provides an illusion of a more traditional \"everything on the same server\" API. Netflix, among others, uses this type of approach.

\n

Microservice architectures emerged and evolved for the needs of large internet-scale applications. The trend was set by Amazon far before the appearance of the term microservice. The critical starting point was an email sent to all employees in 2002 by Amazon CEO Jeff Bezos:

\n
\n

All teams will henceforth expose their data and functionality through service interfaces.

\n

Teams must communicate with each other through these interfaces.

\n

There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

\n

It doesn’t matter what technology you use.

\n

All service interfaces, without exception, must be designed from the ground up to be externalize-able. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world.

\n

No exceptions.

\n

Anyone who doesn’t do this will be fired. Thank you; have a nice day!

\n
\n

Nowadays, one of the biggest forerunners in the use of microservices is Netflix.

\n

The use of microservices has steadily been gaining hype to be kind of a silver bullet of today, which is being offered as a solution to almost every kind of problem. However, there are several challenges when it comes to applying a microservice architecture, and it might make sense to go monolith first by initially making a traditional all-encompassing backend. Or maybe not. There are a bunch of different opinions on the subject. Both links lead to Martin Fowler's site; as we can see, even the wise are not entirely sure which one of the right ways is more right.

\n

Unfortunately, we cannot dive deeper into this important topic during this course. Even a cursory look at the topic would require at least 5 more weeks.

\n

Serverless

\n

After the release of Amazon's lambda service at the end of 2014, a new trend started to emerge in web application development: serverless.

\n

The main thing about lambda, and nowadays also Google's Cloud functions as well as similar functionality in Azure, is that it enables the execution of individual functions in the cloud. Before, the smallest executable unit in the cloud was a single process, e.g. a runtime environment running a Node backend.

\n

E.g. Using Amazon's API gateway it is possible to make serverless applications where the requests to the defined HTTP API get responses directly from cloud functions. Usually, the functions already operate using stored data in the databases of the cloud service.

\n

Serverless is not about there not being a server in applications, but about how the server is defined. Software developers can shift their programming efforts to a higher level of abstraction as there is no longer a need to programmatically define the routing of HTTP requests, database relations, etc., since the cloud infrastructure provides all of this. Cloud functions also lend themselves to creating a well-scaling system, e.g. Amazon's Lambda can execute a massive amount of cloud functions per second. All of this happens automatically through the infrastructure and there is no need to initiate new servers, etc.

\n

Useful libraries and further reading

\n

The JavaScript developer community has produced a large variety of useful libraries. Before writing something from scratch it is always worth checking whether a well-maintained solution already exists.

\n

You can take advantage of your React know-how when developing mobile applications using React Native, which is the topic of part 10 of the course.

\n

The course itself continues beyond part 7: part 8 covers GraphQL, part 9 TypeScript, part 10 React Native, part 11 CI/CD, and part 12 containers. The full course contents are listed on the course page.

\n

The following external resources are good places to go deeper on React patterns, code quality, and the broader ecosystem:

\n\n
","frontmatter":{"mainImage":{"publicURL":"/static/2184b1c35920cfc7a09e10660dea04eb/part-7.svg"},"part":7,"letter":"c","lang":"en"}}},"pageContext":{"part":7,"letter":"c","lang":"en"}},"staticQueryHashes":["3128451518"]}