Svelte 3 Up and Running
上QQ阅读APP看书,第一时间看更新

Building a journaling app

Throughout the following chapters of this book, we'll build a proof-of-concept application using Svelte 3 – a journaling app:

Figure 1.2 – Screenshot of the completed app

App features

This app features three main views:

  • The starter view is a list of all the journal entries for a given day; a date picker lets users select the day.
  • Users can add new content using a form that lets them type it in freely.
  • Content is presented to users when they select a journal entry, rendering the input text as Markdown.

The app requires authentication before users can read or write any journal entries, and it uses OAuth 2.0/OpenID Connect to achieve that.

Data is stored inside a back-end service, which runs separately from our application (remember that we're building a JAMstack app!), and our front-end communicates with the back-end service via RESTful APIs.

While this proof-of-concept app has simplified, limited functionality, it does help us learn all the core capabilities of Svelte 3 (and a few other things too). The concepts we'll be exploring are applicable both to internal, line-of-business applications, as well as external-facing ones.

The back-end service

In order to keep this book focused on front-end development using Svelte 3, we'll be using a pre-built back-end service that provides persistent storage for the data, as well as identity and access control.

To make your life simple and to let you focus on the front-end, I've built a small service that provides the required endpoints. This is written in Go and is available on GitHub at PacktPublishing/Svelte-3-Up-and-Running or https://bit.ly/sveltebook. You can download the pre-compiled binary for Windows, macOS, and Linux, and launch it on your laptop (usually by double-clicking on the executable) to instantly have the required APIs available for your front-end app to interact with.

Besides being a cheap workaround to the complexity of requiring you to build a back-end, this approach reflects the way modern web applications are built. As the developer working on the front-end portion of your app, you will need to interact with a service using predefined APIs that are maintained by a different team.

You might not have knowledge of how the back-end service works (and, truthfully, you might not want to either), and the service might be written in a completely different stack, just like this back-end app is written in Go. As we saw in the previous sections, in fact, many JAMstack applications interact with services that are maintained by completely different organizations within the company, or even different companies.

Important note

The source code for the back-end service, written in Go, is available on GitHub for you to look at and modify as you please.

The service includes common RESTful endpoints to store, retrieve, and search objects (journal entries).

It also features a mock OAuth 2.0/OpenID Connect implementation to provide identity services. This was built from scratch, but it includes just the bare minimum features to support the needs of the sample front-end application.

While the back-end service is functional, because its purpose is just to aid the development of the front-end application in this book, it is full of sub-optimal practices. In short, do not use this app or any of its code in production as is. This is especially key for the access management part, which is likely unsafe for any real-world applications; instead, you should rely on your organization's directory or, if building a consumer-facing app, on trustworthy identity service providers.