.. _getting-started: Getting Started =============== We will help you to use Remote Settings in your application! .. _go-to-prod: Create a new official type of Remote Settings --------------------------------------------- Basically, you will have to go through these 3 steps: 1. Design your data model (see below) and prepare the list of colleagues that will be allowed to review your data 2. Request the creation of your collection using `this Bugzilla ticket template `_ 3. While the collection is being created, setup the `Mozilla VPN `_. If you are mentioned as an editor or reviewer, you will be given the appropriate VPN group automatically. Once done, you will be able to login and edit your records on the Admin UIs: - https://remote-settings.mozilla.org/v1/admin/ The records will then be publicly visible at ``__ Don't hesitate to contact us (``#delivery`` on Slack) if you're stuck or have questions about the process! Check out the :ref:`screencast to create, request review and approve changes `, or :ref:`our FAQ `! Environments ------------ +--------------+---------------------------------------------+-----------------------------------------+-----------------------------------------+ | | DEV | STAGE | PROD | +==============+=============================================+=========================================+=========================================+ | Base URL | https://remote-settings-dev.allizom.org/v1/ | https://remote-settings.allizom.org/v1/ | https://remote-settings.mozilla.org/v1/ | +--------------+---------------------------------------------+-----------------------------------------+-----------------------------------------+ | Main purpose | Try out API and new use-cases | QA data changes | Deliver data within minutes | +--------------+---------------------------------------------+-----------------------------------------+-----------------------------------------+ | Deployed on | pull-request merges | tagged versions | approvals | +--------------+---------------------------------------------+-----------------------------------------+-----------------------------------------+ | Access | Public via LDAP Auth | VPN via LDAP groups | VPN via LDAP groups | +--------------+---------------------------------------------+-----------------------------------------+-----------------------------------------+ | Permissions | - Create collections, groups, records | - CRUD records | - CRUD records | | | - Approve own changes | - Approve other's changes | - Approve other's changes | +--------------+---------------------------------------------+-----------------------------------------+-----------------------------------------+ .. note:: In order to switch Firefox from PROD to DEV or STAGE, use the `Remote Settings DevTools `_! About your data --------------- Name your collection in lowercase with dashes (eg. ``public-list-suffix``, `examples `_). The Admin UI automatically builds forms based on some metadata for your collection, namely: - the list of fields to be displayed as the list columns (eg. ``title``, ``comment.author``) - a JSON schema that will be render as a form to create and edit your records (`see example `_) - whether you want to control the ID field or let the server assign it automatically - whether you want to be able to attach files on records .. note:: If your client code expects to find 0 or 1 record by looking up on a specific field, you should probably use that field as the record ID. ``RemoteSettings("cid").get({filters: {id: "a-value"}})`` will be instantaneous. By default, all records are made available to all users. If you want to control which users should have a particular entry, you can add a ``filter_expression`` field (see :ref:`target filters `). Records vs. Attachments? '''''''''''''''''''''''' Since the diff-based synchronization happens at the record level, it is recommended to keep your Remote Settings records small, especially if you update them often. It is important to design your data layout carefully, especially if: * you have too many records (eg. > 2000) * you have big amounts of data (eg. > 1MB) * your data cannot be easily broken into pieces * your updates are likely to overwrite most of the collection content Consider the following summary table: +-------------------------------------+--------------------------------------+-------------------------------------+ | Strategy | Pros | Cons | +-------------------------------------+--------------------------------------+-------------------------------------+ | Many small records | - Efficient sync | - Costly lookups in client | | | - Easier to review changes in Admin | - Updates potentially harder to | | | UI | automate | | | | | +-------------------------------------+--------------------------------------+-------------------------------------+ | Few big records | - Efficient lookups in client | - Harder to review changes within | | | | records in Admin UI | | | | - Memory usage in client | | | | | +-------------------------------------+--------------------------------------+-------------------------------------+ | Attachments | - No limit in size & format | - No partial update | | | | - Packaging attachments in release | | | | binary is feasible but tedious | | | | (source_) | | | | | +-------------------------------------+--------------------------------------+-------------------------------------+ .. _source: https://searchfox.org/mozilla-central/rev/dd042f25a8da58d565d199dcfebe4f34db64863c/taskcluster/docker/periodic-updates/scripts/periodic_file_updates.sh#309-324 - See our :ref:`tutorial for file attachments ` .. _collection-manifests: Collection manifests -------------------- Both STAGE and PROD collections attributes and permissions are managed via YAML files in the `remote-settings-permissions `_ Github repository. If you want to accelerate the process of getting your collection deployed or adjust its schema, in DEV, STAGE or PROD, you can open a pull-request with the collection, and the definition of ``{collection}-editors`` and ``{collection}-reviewers`` groups. Check out the existing ones that were merged.