Search code examples
jsonjsonschemaelmstatic-data

Using static data in Elm applications: parse JSON or use Elm values?

I am about to start development on an Elm application that is mostly about displaying a data set. The data will be prepared in several JSON files (including different languages for text), specified by JSON schemas. This data base will not go away, since other use cases for the shared dataset exist.

I see two options for accessing these data from Elm now.

Retrieving and parsing JSON at runtime

Using json-schema-to-elm or similar, I can generate data types and parsers from the schemas I have. Then, at runtime, I load the JSON the app needs and parse it.

Advantages

  • Always uses current data without extra work.
  • App size is not bloated by the data.

Disadvantages

  • Runtime impact of JSON retrieval.
  • Runtime impact of JSON parsing.
  • The data have to be stored in the Model.

Converting JSON into Elm values at compile-time

With a hand-written compiler (maybe based on the types generated by json-schema-to-elm), I can statically convert the JSON data into Elm code. The data thus ship with the app and can be accessed using Elm primitives.

Advantages

  • Direct access to the data, no runtime impact.
  • Data are not stored in the Model.

Disadvantages

  • App needs to be recompiled when data changes.
  • App is huge because all data need to be included.

Tradeoff

Based on above listing, here is my conclusion.

  • I expect the data to change rarely (after a curation period in the beginning). Re-compiling and -deploying the app should be simple; there will be no outside interaction to be careful about.
  • The app is supposed to be used in mobile settings, so saving network requests and processor load is a good thing.
  • I will want to have a standalone version for offline use, so having a monolith may even be helpful.
  • The actual data set will not be too large; I estimate a few hundred kilobytes at most, even including all languages.

Therefore, I think that going with precompiled Elm values is the better solution in my case.

My question is: Have I missed any aspects of either approach that would impact my tradeoff? Are there other approaches I should consider?

Note that I'm not worried about the specific tools right now; this is more of a conceptual, design question.

Solution

  • To consolidate the conversation in the above comments:

    The two packages you mentioned, json-schema-to-elm and json-to-elm are roughly similar in their output. They both render Elm source code containing types, decoders, and encoders.

    The main difference is in their input:

    • json-schema-to-elm takes JSON Schema as input. This is useful when your JSON becomes more complex than can be described with an example, but it also requires that you write a schema file for all the JSON you want modeled.
    • json-to-elm takes example JSON values as input. This is useful when your JSON model is relatively simple.

    Personally, I'd try to write some proof of concepts to see if there really are any detrimental runtime inefficiencies. You could always just keep json values as strings in the .elm file - that would ease offline access, avoid network traffic, and really the only downside is a once-per-value decoding of each json input, since if it doesn't change, you won't need to decode it again.

    Note: if you go the route of embedding json as string values in .elm files, be aware of the multi-line string syntax which will help avoid lots of escape characters in raw json strings