Skip to content

Annoyingly difficult things

Jump to bottom
Atul Varma edited this page Aug 11, 2021 · 1 revision

There are some things that are really easy to do with other JustFix.nyc codebases which are not very easy to do on the Tenant Platform.

Here are some of them.

Integrating with third-party services in the browser

Normally if you want to integrate with a third-party service on the client-side, you just plop an inline script from the service's documentation into your site's index.html and you're done.

Not so with the Tenant Platform! It uses Content Security Policy (CSP) to protect users and as such, adding inline scripts takes some extra work.

For an example of what this involves, see #1439, in which Amplitude support was added. Specifically, see the changes to the project/context_processors.py file.

Doing anything fancy with JavaScript in the browser

As stated in the core principles, the platform's commitment to progressive enhancement makes it a bit harder to do fancy things on the front-end with JavaScript, because you can't always assume that JavaScript is available. This can make it challenging to add what seem like otherwise straightforward functionality on most apps.

For examples of this, see:

  • #192, which added a progressively-enhanced geosearch autocomplete along with a <ProgressiveEnhancement> component.

  • #1954, which added the "edit" and "save/cancel" buttons to the account settings page.

The commitment to progressive enhancement also means that pages need to be capable of being rendered in their entirety on the server-side. See multi-pass server-side rendering for more details on how that works. For an example of it in action, see anything that uses the <QueryLoader> component, such as #1673.

Creating forms in the browser

Also due to the platform's commitment to progressive enhancement, all forms need to work via standard POST requests. This legacy form submission places significant constraints on the kinds of forms you can make, and also introduces layers of abstraction in the back-end that can make form processing harder to understand.

For an example of this in action, see #2013, which added the "housing voucher" field to the account settings page.

Making API requests to the back-end from the browser

GraphQL was ultimately chosen as the protocol through which the front-end communicated with the back-end because we really wanted type safety between the two codebases.

However, in exchange for type safety, GraphQL also brought additional complexities:

  1. It takes more effort to understand GraphQL than REST.

  2. The Graphene library we use on the back-end has its own idiosyncrasies that can make it difficult to understand how back-end API requests are handled.

  3. The sheer verbosity of GraphQL requests prompted the need for a separate "querybuilder" component which wrote them for us, which itself takes even more work to understand.

Clone this wiki locally