Contributing

Contributing

We would love for you to contribute to the FireFly stack aka the Developer API. Here are the guidelines we would like you to follow:

• Contributing

  • Got a Question or a Problem?

  • Missing a Feature?

  • Coding Rules

  • Tenets

Got a Question or a Problem?

For questions and inquiries relating to FireFly stack, consider reaching out to us at slack via #firefly-interest

Missing a Feature?

If you would like to implement a new feature, please consider the size of the change in order to determine the right steps to proceed. See the Merge Review for more details. For Major Features it’s highly recommended to open an issue, and discuss during office hours.

Coding Rules

To ensure consistency throughout the source code, keep these rules in mind as you are working:

Must:

• The code must pass type checking and fullfil all the TSLint rules.

• All business logic that is not associated with transforming a response to graphql representation MUST reside in a seperate micro-service.

Should:

• All features or bug fixes should be covered by tests (Integration preferred).

• All atomic entity types (ie: Artist, PodcastShow, Track, Playlist) should have a working deeplink provided as the url field.

Tenets

1. Security/Trust: Amazon has a widespread reputation of being highly trustworthy and secure with customer data. As such regardless of service integrations, all metadata exposed must not pose a potential risk to the customer’s privacy/security even when requested/approved by the customer for a 3P partner. (ie: FireFly will not risk exposing any metadata that would flag this service as a Red Tier regardless the use-case)

2. Scalability: As scope increases and use-cases get adopted, this service must retain the ability to scale and cater to a multitude of micro-service integrations without compromising existing flows. The key mantra to new feature/service integrations is: “Pay only for what you use”. Meaning costs associated with metadata that was requested should not be compromised by metadata that wasn’t requested.

3. LightWeight: Business logic outside of aggregation and ETL: ‘Extract, Transform, Load’, must not be introduced into MusicFireFly Service.

4. Reliability: This service in order to act as a singular aggregation layer must provide fallback/redundant mechanisms for gracefully handling requests under service interruption as well as exceptional erroneous circumstances.

5. Extendability: In future the goal is to externalize the MusicFireFlyService on developer.amazon.com (http://developer.amazon.com/) similar to the AlexaKit for AmazonMusic. As such the on boarding process for Clients must be have a path to self-serviceability, while allowing internal clients (AmazonMusic service owners) a streamlined flow for new service/feature integration.