Client Services

What is it?

A support team for all the user interface platforms!

  • Front end team(s)
  • Mobile team(s)
  • Wordpress
  • Any future clients

Who is it?

  • Mike Elliott - Engineering Manager
  • Cory Brown - Staff Engineer
  • Somebody in the future - Senior Engineer (probably)

What do we do?

  • Maintain and govern client, client-support and infrastructure projects that don't belong to a specific product team
    • Base React Components
    • Sitewide stuff like header, etc
    • Node services!
    • Orphaned features or fixes that can't find home
    • Some internal apps (enterprise tools, maybe others)
  • Act as liaison between the client org/architecture and the rest of engineering and product
  • Help with training, direction, and architecture decisions & discussions on client teams
  • Work with YOU

What DON'T we do?

  • Gatekeep
  • Pass down ivory tower or dictatorial architecture decisions to other teams
  • Implementation of product features, including in services we own and maintain
  • Ignore your concerns and requests

What's already been done

(thanks to the whole FEE team)

  • Base React Components Resurrection
  • Progress on Node proxies, switching to express
  • OTM - sharable, composable, embeddable features
  • Lots of documentation, some improved logging
  • Sitewide stuff (404 page, header fixes, design backlog)
  • SPA-ification of most of the web front end
  • Communicating with many of you about what we are doing and how we're doing it
  • The creation of the Client Services team in the org
  • Business case on API aggregate gateway
  • Spikes on API aggregate gateway
  • Basically the past 18 months of standardization and quality controls, "fixing" our architectures

Current state of the clients

Current state of the clients

Short term goals

(Estimated 4-6 weeks)

  • One True Marketplaceā„¢ shipped (not us, but a dep)
  • Unify other duplicated work modeled after OTM (including extending Base React Components and unifying discrepencies with Ent_web)
  • Replace Hapi with Express in Pipsqueak
  • Identify the pieces of the clients' Node servers that can be pulled out
  • Initialize a "New Thing" codenamed Singer - API aggregate gateway - in integration hitting endpoints
    • Using Apollo Server Graphql and Apollo Engine/Platform (and later, likely, Apollo Client)
      • JS vs. TS
    • Researched Gloo & Sqoop, other graphql server solutions (gql-yoga, gql-express)

Medium term goals

(Estimated 2-3 months)

  • Initialize, provision, and ship "Singer"
  • Implement Auth in Singer
  • Implement CTA widget as a guinea pig for Singer's first milestone
  • Start OTM as next Singer milestone
  • Define proper client boundaries aligned with product goals
    • Establish the ideas of Marketplace, Credit Reports, and/or however product defines it's "solutions" as concepts with clear boundaries
  • Starve the clients' coupled servers (pip, ent_web)Ā 
    • Get the extracted pieces into Singer or wherever they really belong

Long term goals

(Ideally within 6-8 months, now we're getting weird though)

  • Implement schema stitching and "graduation" logic between 1st & 3rd party services in Singer
  • Get each client decoupled from respective servers, replaced by the single Singer endpoints
  • Segregate client code bases by sensible boundaries, and keep them client-only (need product help with this!)
    • Abolish the ideas of pipsqueak, enterprise_web, and nav_web as concepts
  • Grow this team
  • ... Profit! (for real though)

The future

The future we want

But why?

  1. To end duplicating work and features across different delivery mechanisms and 1st/3rd parties
  2. To remove our big centralized full-stack code bases as single points of failure - flexibility with deploys and better parallelization of product work
  3. To have 1st party experimentation via Singer, 3rd party gets stable code, all shared, composable, embeddable
  4. To create a unified API aggregate gateway for clients (lots of us have been talking about this for a long time)
  5. To remove server-side & proxy hurdles on client projects - this is a massive win for the front end team(s) and adequately separates concerns
  6. To create flexibility in code & feature organization, directly allowing scalability in team organization
  7. To decrease burn rate by increasing efficiency

Remember before K8s?

Questions?

Concerns?

Opinions?

Feedback?

Client Services at Nav

By Michael Elliott

Client Services at Nav

Introduction and Roadmap of the Client Services team at Nav

  • 940