Backend Developer in 30 Days: Acquire Skills on API Designing, Data Management, Application Testing, Deployment, Security and Performance Optimization

Cover Page
Title Page
Copyright Page
Dedication Page
About the Author
Acknowledgement
Preface
Errata
Table of Contents
1. Building Multi-User Apps
    Structure
    Objective
    Digital transformation and a little history
        Digital transformation and the Internet
            Software transformation
    Designing apps to solve real-world problems
        Caring for user problems as a back-end developer
        Finding a problem to solve
    Define a sample use case: The Pizza Place ordering system.
    Defining functional and non-functional requirements
        An ineffective way of collecting requirements
        The requirement definition cycle
            Find out what is the problem your client is trying to solve
            Get a detailed picture of the business.
            Request the help of one of your client’s domain-experts
            Learn how the existing process works today
            Build prototypes and revise requirements
            Use case: Defining requirements for the Pizza Place
    The modern system design: a ten thousand-feet view
        Getting the front-end out of the way
            Building blocks
    Conclusion
    Questions
2. The Client-Server Architecture
    Structure
    Objectives
    Architecture details
        Abstraction layer: Frontend client and backend client
        Abstraction layer: Data access service client, database server
    HTTP: The language of the web
    Implementing a web server
        The main process
        Serving a response
        Multi-user support with multi-threading
    Using a production-ready server
        Enabling HTTPS in Express
    Layered architecture: Fully splitting the client from the server
        Splitting clients
    Client versus server computing
    Web servers as stateless services
        Storing session data
    Use case: Applying a client-server architecture to the Pizza Place app
    Client server versus peer-to-peer
    Conclusion
    Questions
    References
3. Designing APIs
    Structure
    Objectives
    What is an API?
        Functions as contracts
    Interfaces and design patterns
    Remote APIs: RPC, SOAP, REST, and GraphQL
        Building a remote API with RPC/gRPC
            Build the gRPC server
            Build the gRPC client
            When to use gRPC
        SOAP and web services
    Building REST APIs
        Actions versus HTTP request methods
            Naming resources
            Singular versus plural
        Relationships
        Versioning
        Caching
    Effective REST APIs: HATEOAS
        Building APIs with GraphQL
    Building standalone APIs
        Standalone API: Headless CMS
        Standalone API: Public APIs
    Use case: Designing a remote API for the Pizza Corner
    Conclusion
    Questions
    References
4. End-to-End Data Management
    Structure
    Objectives
    Defining the application state
        Hardware storage
    Understanding in-memory data storage
        In-memory cache
        In-memory databases
        Simple storage in text and binary files
    Understanding complex data storage
        SQL or NoSQL?
        Document databases
            High locality
            Few relationships
            Unstructured data
        Relational databases
            Models are related but independent
            Multiple relationships
            Fixed structure
            Normalization
        Graph databases
            Data with a lot of connections
            Data where the relationships are first-class citizens
        Scalability
        File storage repositories
        Beyond technical requirements
    Indexing
        Reducing time complexity
        Example: Benchmark the impact of indexes in SQLite
    Backup and recovery
        Backup database files
        Creating backups with activity logs
        Backup through replication
        Tackling gaps in backups
    Designing data storage in a production system
        Choosing a deployment strategy
            Database and application share a server
            Deploy database in its own server(s)
            Embedded databases
            Combining databases to approach complex use cases
    Use Case: Defining a data model for the Pizza Place application
        Requirement: Users should be able to see the menu on their phones or computers
            No attributes, fixed size of ingredients
            No attributes, dynamic list of ingredients
            With attributes, dynamic size
        Choosing a data store for storing the pizza menu
            The winner
            Scaling the database
    Conclusion
    Questions
    References
5. Automating Application Testing
    Structure
    Objectives
    Certainty through testing
    Manual testing
        Types of manual tests
        Building effective manual tests
            Creating a test plan
            Executing the test plan
            Creating detailed reports
            Validating fixes
            Update test plan
        Advantages of manual testing
            Explorability
            Horizontal validation
            User-centered vision
        Manual testing and Agile
        Let others test your code
    Automated testing
    Unit testing
        Testing in isolation: Doubles, stubs, and mocks
            Isolated code is easier to debug
            Isolating test dependencies
            Test mocks
            Stubs versus mocks
        Coverage
            To use coverage or not to use it
        Test-driven development
    Integration testing with Selenium
        Defining a test environment for integration testing
        Simulate a test environment close to production
    Testing and CI/CD
    Other automated tests: Static code analyzers
    Defining effective test cases
        Defining a single use case per test
        Do not mock everything
        On equal conditions, prefer unit tests over integration tests
    Non-functional testing
        Application security and penetration testing
        Load testing
        Performance testing
        Accessibility testing
    Conclusion
    References
6. Securing Applications
    Structure
    Objectives
    The CIA triad: Confidentiality, Integrity, and Availability
        Confidentiality
            Loss of confidentiality
        Integrity
            Loss of integrity
        Availability
            Loss of availability
    Access Control: Authentication and authorization
        Authentication
            Identification: Username and password
            Problems with passwords
            Best practices for passwords
            Identification: Multi-factor authentication
            Single Sign-On
        Authorization
            Roles and groups
            Least privilege principle
    Use case: Implementing basic authentication and authorization for the Pizza Place
        Identify user roles
        Building an authentication service
            Define user management storage
            Define password-related protections
            Build web forms for signup and login
            Apply authorization controls
            Translate a high-level authorization map to implementation details
            Using scopes to check authorization
            Test access control
    Federated authorization
        Pros and cons of federated authentication
        Security Assertion Markup Language (SAML)
        OpenID
            OAuth2
            Terms
            Request an authorization code
            Request an access token
            The implicit flow
            Building OpenID from OAuth2
    Building security into the application’s design
        Creating a Threat Model
            Decompose the application
            Determine and rank threats
            Determine countermeasures and mitigation
    OWASP Top 10: The most common vulnerabilities
    Conclusion
    Questions
    Resources
7. Handling Errors
    Structure
    Objectives
    Why do we need to handle errors?
        Understanding common causes of errors
    Types of error handling
        Exceptions
            Using stack traces to debug problems
            Defining exception types
            Catching exceptions
            Errors validated at compile time
        Errors as return values
    Implementing good exception handling
        Preventing all the errors we can
        Handling and mitigating errors in production
            Defining good error messages
            Bubble up!
            Providing a fallback
            Letting the error propagate
    Finding production errors with logging
        Anatomy of a log entry
        What to log?
        Designing good log and error messages
        Persisting log entries to file
    Handling errors in distributed systems
    Using case: Logging errors with the ELK stack
        Logging errors locally
        Configuring Logstash
            Logstash input
            Logstash filter
            Logstash output
        Installing and configuring Elasticsearch and Kibana
        Creating Kibana dashboards
    A/B testing and gradual deployment
        Creating a deployment plan
    Conclusion
    Resources
8. Adopting Frameworks
    Structure
    Objectives
    What problems do frameworks fix?
        Solving existing problems
        Frameworks and design patterns
        Libraries and frameworks
            Pre-building abstractions
        Framework’s benefits
    Common patterns addressed by frameworks
        Automation tools and package managers
            Automation tools
            Native package management
        Handing web requests (e.g. Spring MVC, Django)
            How frameworks are born: The use of the Spring framework
            About MVC
            Dependency Injection
            Spring’s XML configuration
            Code-based configuration
            Annotation-based configuration
            Spring MVC
            More MVC: Express
            The downfall of MVC
        Database access with ORMs
            JPA and Hibernate
            Mapping tables to entities
            Inserting and querying data
            More ORMs: Python’s Django ORM
            The downsides of ORM
    Choosing a framework
        The impact of community
    When not to use frameworks
        Learning the framework instead of using the basics
        Adding debugging complexity
            Zero-cost abstractions
    Conclusion
    References
9. Deploying Applications
    Structure
    Objectives
    Defining a robust deployment process: CI/CD
        Before CI/CD
            A step forward: Deployment scripts
        The advantages of a CI/CD pipeline
    Creating reproducible environments
        Moving out of shared environments
            Advantages of isolated and reproducible environments
    Version control
        Git
            Creating a Git repository
            Staging and committing new files
            Making changes to existing files
            Commit details
            Branches
            Merge
            Remote repositories
            Cloning repositories
        Merging conflicts
        Using Git hooks
        Git to enforce reproducible code
        SVN and other CVS
    Virtual machines
        Virtual infrastructure
    Containers (Docker)
        VMs versus containers
    Working with stateless containers
    Use case: Creating a reproducible deployment environment for the Pizza Place app using Git and Docker
        Setting up the application
            The web directory
            The nginx directory
        The docker-compose.yml and nginx.conf files
        Adding Git
        Docker in CI/CD
        The trade-off
    Conclusion
    Questions
    Resources
10. Creating High-performance Apps
    Structure
    Objectives
    Measuring to improve the performance
        Synthetic testing versus RUM
        Using percentiles
    Improving the performance
        Improving the performance with caching
            Defining reading and writing load
            Cache patterns
            Cache-aside and read-through cache
            Caching write-heavy applications
            Write-through cache
            Write-behind cache
            Choosing the right caching strategy
            Eviction policy
            Other caching tools: Proxies and CDNs
            Use case: Caching long-running operations with Redis
            Using Jedis
            Using Redisson
        Improving the performance with distributed systems
            Keeping data consistency
            Data consistency in replicas
            Multiple read replicas, single write replica
            Eventual consistency versus strong consistency
            Data consistency in sharding
        Microservices
        Improving performance using asynchronous communication (queues)
        Improving the performance using asynchronous programming
            Promises and futures
    Conclusion
    Questions
    References
11. Designing a System
    Structure
    Objectives
    The system design process
        Example: The Pizza Place (at scale)
    Defining and clarifying requirements
    Defining the system’s interface
    Defining data models
    Calculating the system scale and size
        Estimating the storage size
        Estimating QPS
        Estimating the storage throughput
        Calculating the cache size
        When to stop estimating the size
    Creating high-level and low-level designs
        Defining a high-level design
            Defining the use case flow
            Finding gaps in assumptions
        Defining a low-level design
            Designing the client
            Designing the web server
            Designing the service layer
            Designing the database layer
            Defining a distributed database strategy
            Defining read and write replicas
            About scaling the file storage
        Integrating each layer
            Client to server
            Web server to services
            Services to database
            Overall low-level design
    Identifying failure points
        Failure case: A web server goes down
        Failure case: A microservice instance goes down
        Failure case: The file storage service goes down
        Failure case: A node in the service queue goes down
        Failure case: A node in the cache layer goes down
        Failure case: A database server goes down
        Failure case: The infrastructure for a whole region goes down
        Extra considerations about failure management
    Conclusion
    Questions
    Resources
12. Bootstrap Your Career Path
    Structure
    Objective
    Defining the expectations on junior developers
        Joining our first development team
        Following guidance from other developers
    What makes a senior developer?
        Characteristics of a senior software developer
    Improving hard and soft skills
        Improving technical skills
        Improving people skills
            Practicing conflict resolution
            Working on communication skills
    Preparing for technical interviews
        Getting an interview
            Building a good resume
            The importance of networking
        Improving interview skills
        The technical interview process
            Approaching coding problems
            Using data structures efficiently
            Using algorithms efficiently
            Coding a solution
            Getting better at coding interviews
            Working on system design interviews
            Take-home assignments
            Approaching non-coding modules
            Asking the right questions
    Finding mentors
    Finding resources to keep learning
    Conclusion
    Resources
Index