The real need for Iglu Server against static Iglu repository

Hey everyone,
New Snowplow (Community Edition) user is here :raised_hand:
First of all, I would like to express my admiration for the project and the community.

Currently, I have only one topic that is not clear for me.

In the documentation it says:

“Some components of Snowplow require an Iglu Server, and a static repo will not work.”

Even though it’s rather easy to have an Iglu Server with a database via Terraform, still, If a static Iglu repository is mainly enough, I would like to host mine via s3.

So my question is:
When is a static Iglu repository not enough for some components of Snowplow? And what are those components?

Thanks :pray:

Hey @akocukcu - so this documentation is somewhat out of date.

All components of the pipeline should now work with a static site repository assuming that you are using the latest versions of igluctl which ensures the correct file structure is present in S3.

The main reason to use Iglu Server instead is that it allows for API driven controls of available schemas (think CI/CD flows) as well as allowing you to define keys that secure your schemas so that they are not internet accessible (which is a little trickier to achieve with an S3 website).

The warnings are generally there from a time when static registries were missing the schema list feature. As josh says, newer versions of igluctl will now generate this for you so it should be mostly compatible (unless you specify igluctl static s3cp --skip-schema-lists for some reason).

Beyond API keys, I believe superseding schemas also requires an actual Iglu Server if you ever need to use that feature. The server will also enforce immutability of schemas too, which can help maintain the integrity of your pipeline.

All clear now :nerd_face:

Thanks both :raised_hands:

@akocukcu have also updated the docs to hopefully be a bit clearer on this point in that it is no longer required to run a full pipeline. Thanks for posing the question!

1 Like