The Developer Kitchen Sink
The following is a list of resources to help you with your journey learning Franklin and Milo.
If you have questions, ask them here: https://milo.adobe.com/community
If you have a question and don't know where to ask (or is private), use: https://git.corp.adobe.com/orgs/wcms/discussions
Remember: share early and share often.
https://github.com/adobe/helix-home/blob/main/docs/architecture.md#aws-delivery-stack
Above you will find the Franklin architecture diagram.
In short, Franklin takes documents created in Word or Google Docs and converts them to markdown (.md). These files live in an object store (S3). For code (JS & CSS), files pushed to Github will be automatically copied to another object store. When a request happens, JS & CSS are delivered straight off the object store and the MD is converted to HTML at time of request.
Note: there is no server-side extensibility in Franklin. All functionality should be done client-side or a 3rd party service (I/O Runtime).
It is highly encouraged a developer has a basic understanding of HTML, CSS, and JS. A deep understanding of ES6 is strongly encouraged.
- Node v16+
- NPM 8+
Franklin sits on a serverless architecture. This means you do not "provision" anything to get up and running. The URLs you use for Franklin can be tied back to your project's github information:
https://{branch-name}--{repo-name}--{repo-owner}.hlx.page
- DOCX to MD to HTML
- Viewing HTML without the head tag (
*.plain.html) - XLSX to JSON
- Creating indexes of content (query-index.yaml / query-index.json)
- Creating sitemaps from content indexes (helix-sitemap.yaml)
- Handle form submissions
- Handle previewing and publishing content
- Ability to upload PDF and SVG
Franklin is a CMS application. You can think of Milo as a Franklin SDK for creating sites for Franklin. Milo comes with features to extend Franklin capabilities to make building sites for adobe.com easier.
When a Milo-based project is created, it will use Milo as a central place for many common features. Including:
- Blocks (aka components)
- Localization
- Authoring enhancements - library, tools, etc.
- Globalization (GeoRouting)
- General purpose utilities (SVGs, icons, placeholders, link decorators, etc.)
Milo developer brown bag (skip to 24:05)
Milo Performance Brown Bag - A deep dive into Milo's performance life cycle.
Build a milo-project from scratch
Covers creating a new repo, setting up content, tying code and content together, and handling permissions for content. A few extras as well.. anatomy of a consuming project, debugging, relationship between milo and consumers, etc.
Some pieces of content and code must live in specific places in order for them to work. The following provides some guidance on these pieces.
The content root is where you content should live. This can be / or it can be something like /acrobat (www.adobe.com/acrobat) this is to help many projects share the same domain.
Setting the code root can also help to avoid JS & CSS collisions when multiple projects share the same domain:
There are certain files that cannot live in your codeRoot or contentRoot paths. Some of these files will live in github, and some will live in SharePoint.
- head.html
- fstab.yaml
- helix-query.yaml
- helix-sitemap.yaml
- .hlxignore
- helix-version.txt
- .helix
- config.xlsx - Used to set cache flushing credentials
- headers.xlsx - Used to set headers for the entire site
- metadata.xlsx - Used to set shared metadata properties across the site (much like Inherited Page Properties in AEM)
- redirects.xlsx - Used for redirects
We try to make names as human readable as possible. While true or false can be developer friendly, they are not human friendly. Instead of {true|false} we prefer {on|off}.
It's also best to not put boolean-like values as part of query parameters as they are harder to remember:
// good
?martech=off// bad
?disableMartech=onWhen architecting a solution where a human is involved, please try to keep this guidance in mind.
- Git workflow and playing/previewing with branches with Milo / Franklin
- Milo Blocks and how can u create a new one
- Authoring
- Metadata
- Running Milo locally with HTTPS
- PR and Checks
- Milo Release Workflow
- How / Why you must care about performance of your code (as opposed to how it was writing server side code in AEM)
- Unit testing
- Working / debugging out of your local environment
- Localization overview
- Using Adobe I/O
- Workflow equivalent in Franklin / Milo
- Permissioning model in Franklin / Milo
Session 1 : Franklin/Milo Principles
Session 2 : Milo Authoring refinement
Session 3 : Milo Working processes
Session 4 : Milo Performance