Frontend APIs powering fast paced product iterations

Front-End APIs
Powering Fast-Paced Product Iterations

Speakers
Jeff Weiner
Chief Executive Officer
Aditya Modi
Staff Software Engineer
Karthik Ramgopal
Sr Staff Software Engineer

Overview
History and evolution of frontend APIs at LinkedIn
Our API structure today
Learnings and results
Sneak peek at the future

Mobile v/s Desktop
Feed on mobile Feed on desktopFeed on iPad

Client - Server setup
mobile-frontend-API tablet-frontend-API homepage-frontend-API profile-frontend-API
Android iOS Tablet homepage-desktop-web profile-desktop-web

• Huge API surface and diversity
• No IDL/schema backing API
• Slow iteration speed
Problems?

Client - Server setup
flagship-frontend-API
flagship-android flagship-iOS flagship-desktop-webflagship-mobile-web
Rest + JSON over HTTP2
Mid-tier . . . . Mid-tier

• > 120k QPS
• ~425 developers
• ~30 commits per day
Scale

• Automated continuous release
• commit to production in < 3 hours
• 3 deployments a day
3x3 Deployment

• Backed by Strongly Typed Schemas
• Backward-compatible evolution
• No endpoint versioning
Principles

{
"type": "record",
"name": "TestRecord",
"namespace": "com.linkedin.test",
"doc": "Test",
"fields": [
{
"name": "id",
"type": "String",
"doc": "ID"
},
{
"name": "name",
"type": "String",
"doc": "Name",
“optional”: true
},
]
}
@interface TestRecord : NSObject
@property(nonnull, copy) NSString *id;
@property(nullable, copy) NSString *name;
@end
class TestRecord {
@NonNull public final String id;
@Nullable public final String name;
}
export default DS.Model.extend({
id: DS.attr(‘string’),
name: DS.attr(‘string’)
});
Schema definition
iOS
Android
Web

Entity Modeling
• Return - Collection<Card>

Composite screens
● Two top level resources
■ Invitations
■ PYMK (People You May Know)
● 1 network call to fetch both resources
■ Infrastructure level aggregation support

• Easy to model
• Decouple API from UI
• Client side consistency
Advantages

Client side consistency
• Why ?
○ Good UX
○ Optimistic writes

Can you do this auto-magically?

Payload Cache

Cache Payload

Takes a long time to ship a feature
API Server
1.5 weeks
iOS
2 weeks
Android
2 weeks
Web
2 weeks
Total time
3.5 weeks=+
Use case: Introduce a new kind of notification

• Create new models for every feature
• Write code on each client platform
• Wait for native app release/adoption
Why so long?

Challenge
Cut this down to 1 day!

• Quickly build and release notifications
• Increase user engagement
• Sweet and sticky, just like honey!
Project Honeycomb

• New notifications WITHOUT app updates
• Client side consistency
• Stellar runtime performance
Beyond iteration speed...

• Model based on how the UI view looks
• Similar views grouped into 1 template
• More UI specific logic on API server
View Template API

Share notification
Share Template
● PrimaryImage: URL?
● Title: AttributedString
● Timestamp: Long
● ShareImage: URL?
● ShareTitle: String
● LikeCount: Long? (Default: 0)
● CommentCount: Long? (Default: 0)

Now let’s look at a slightly different notification
Modify Share Template
● Timestamp: Long
● ShareImage: URL?
● ShareTitle: String AttributedString
● ShareSubtitle: AttributedString?
● LikeCount: Long? (Default: 0)
● CommentCount: Long? (Default: 0)

How about something radically different?
Work Anniversary Template
● Timestamp: Long

Something slightly different again?
Work Anniversary/New Position Template
● Timestamp: Long
● BodyText: AttributedString?

How do we return a heterogeneous list?
• Use Rest.li paginated collections. Differentiate between items using a Union.
• JSON payload structure:
{
“elements” : [
{“Share”: {“Title”: “Sarah Clatterbuck shared a…”, ...}},
{“Anniversary”: {“Title”: “Congratulate Nitish Jha…”, ...}},
....
],
“paging”: { “start” : 0, “count”: 10, “paginationToken”: “xydsad”}
}

Minor payload optimization
• Embed the type into the payload to reduce nesting.
• JSON payload structure:
{
“elements” : [
{“Type”: “Share”, “Title”: “Sarah Clatterbuck shared a…”, ...},
{“Type”: “Anniversary”, “Title”: “Congratulate Nitish Jha…”, ...},
....
],
“paging”: { “start” : 0, “count”: 10, “paginationToken”: “xydsad”}
}

• Code-generated response parser
• Bind model to native views
• Write once* per layout, reuse.
Client side rendering

Backward compatibility
{
“elements” : [
{“Stat”: {“Title”: “Your Profile...”, ...}},
{“JYMBII”: {“Title”: “5 Jobs you”, ...}},
{“Share”: {“Title”: “Swati Mathur...”, ...}},
....
],
“paging”: { “start” : 0, “count”: 10,
“paginationToken”: “xydsad”}
}
Drop unknown notification types.

Backward compatibility
Drop unknown fields based on product needs.

• New notification types without client
changes
• Renders faster on the client
Benefits

But… Client side Consistency is lost!

How did we solve the AttributedString problem?
• Model formatted text
• Control formatting from the server
• Impractical to use HTML
AttributedString

AttributedString schema
AttributedString
● Text: String
● Attributes: List[Attribute] BOLD, ITALIC, UNDERLINE etc.
Attribute
● Type: AttributeType
● StartIndex: Int
● Length: Int
● Metadata: Any?

Platform specific binding
Infrastructure provided support
iOS
Android
Web
NSAttributedString
Spannable
HTML
AttributedString

What if we extended this concept to entity mentions?
Model entity mentions also as a custom formatting specifier.
Profile mention Profile mention

Introducing TextViewModel
TextViewModel
● Text: String
● Attributes: List[TextViewAttribute]
TextViewAttribute
● Type: TextViewAttributeType
● StartIndex: Int
● Length: Int
● Metadata: Any?
● Profile: Profile?
● Job: Job?
● Company: Company?
● Course: Course?
Flattened canonical entities as optional fields
Similar to AttributedString

Entity mentions
Entities could be mentioned in different ways.
First Name
Full Name
Position

TextViewAttributeType
TextViewAttributeType
● PROFILE_FIRST_NAME
● PROFILE_FULL_NAME
● PROFILE_HEADLINE
● PROFILE_DISTANCE
● COMPANY_NAME
● COMPANY_HEADLINE
● JOB_TITLE
● ….
If a particular type is used, then the corresponding entity is populated by the server.
● PROFILE_XXX types will populate the profile field for example with the corresponding profile.

Backward compatibility++
Old clients cannot handle new mention types. Always send Raw text though redundant.
{
“title” : {
“Text”: “Sarah Clatterbuck shared this”,
“Attributes”: [
{“Type”: “PROFILE_FULL_NAME”,
“StartIndex”: 0….}
]
}
}

• Singular and Plurals
• Possessive forms
• i10n and i18n
Watch Out

How about images?
Use the same concept as TextViewModel. Introduce ImageViewModel.
ImageViewModel
● Attributes: List[ImageViewAttribute]
ImageViewAttribute
● ImageViewAttributeType
● URL: URL?
● ResourceName: String?
● Profile: Profile?
● Job: Job?
● Company: Company?
● Course: Course?
Flattened canonical entities as optional fields

ImageViewAttributeType
ImageViewAttributeType
● URL
● RESOURCE_NAME
● PROFILE_IMAGE
● PROFILE_BACKGROUND
● COMPANY_IMAGE
● ….
If a particular type is used, then the corresponding entity is populated by the server.
● PROFILE_XXX types will populate the profile field for example with the corresponding profile.
● URL type will populate the image URL
● RESOURCE_NAME will populate the pre-canned resource name.

Rendering Images
● Infra code extracts Image URL out of ImageViewModel
● Load into platform specific image view.
One Attribute: Regular ImageView
Multiple Attributes: GridImageView

Performance considerations
Entities may repeat multiple times within the same notification causing payload size bloat.
Tim’s Profile in ImageViewModel Tim’s Profile in TextViewModel

Solution: Response Normalization
All canonical entities have a unique ID. Use a JSON API like response format.
{
“data” : {
“Profile”: “profile:123”, ...
},
“included”: [
{
“id” : “profile:123”, “firstName” : “Tim”, “LastName” : “Jurka”, ... }
},
....
]
}

Performance considerations (Continued)
All fields from the entities may not be used.
ImageURL First Name and Last Name

Solution: Deco
Deco is a LinkedIn framework that allows selective projection and decoration of fields.
Profile in TextViewModel
ID
FirstName
LastName
Profile in ImageViewModel
ID
ImageURL
Profile in Response
ID
FirstName
LastName
ImageURL

Improved Developer and Product Velocity
9 new notification types in all of 2016
16 new notification types in May and June 2017

API model reduction
42 API models for old UI
6 API models for new UI

Code size reduction
15k LOC app and test code for old UI
3k LOC app and test code for new UI

Future Direction
● Extend to other pages in Flagship
● Extend to other LinkedIn apps like JobSeeker, Recruiter etc.

Out of scope for this talk
● Intricate details of client side consistency management
● Generic Modeling of actions
● Challenges in migrating from the old notifications API to the new one
Find us after the talk, and we’re happy to chat about this and more.

Q & A
amodi@linkedin.com
https://www.linkedin.com/in/modiaditya/

Aditya Modi
kramgopal@linkedin.com
https://www.linkedin.com/in/karthikrg/

Karthik Ramgopal

Frontend APIs powering fast paced product iterations

Recommended

More Related Content

What's hot (20)

Similar to Frontend APIs powering fast paced product iterations (20)

Recently uploaded (20)

Frontend APIs powering fast paced product iterations