Shadowing Practice: 1. Roadmap for backend from first principles - Learn English Speaking with Video

Kies een oefenmodus

Elke modus opent een volledig scherm oefenruimte.

412 zinnen

Als zinnen te kort of te lang zijn, klik op Bewerken om ze aan te passen.

Backend engineering is a very wide scope.

And when I say backend engineering, it is much more than building a set of CRUD APIs.

The way I think backend engineering is about building reliable, scalable, fault tolerant and maintainable code bases and efficient systems.

And if one were to start today to learn backend development,

there are a lot of resources and at least a thousand resources.

But how do you decide what to learn?

How do you prioritize?

How do you see the big picture?

When and how all these different concepts come together?

And this is the reason it takes people years to get their head around a lot of these concepts and principles.

Because people primarily start with a limited scope of training, whether it is from a college or a boot camp or a simple Crud API course.

and they eventually build on top of that with trial and error and with help of other developers over time.

Now I am a backend engineer and I have faced this struggle initially when I started out.

I had to constantly search for resources, learn from other developers, I have read a lot of books on backend development,

I have studied hundreds of open source code bases to see how people in the industry are building stuff

and it was a very time -consuming procedure

and the second problem is people start with back -end development from a particular language

or framework's point of view it could be express or springboot

or ruby on rails and the problem with

that is you look at the problems

that you solve with the lens of your particular language and ecosystem and there are blind spots in that.

Let's imagine you have to switch to a different language.

Let's say you were working with Ruby on Rails for years

and one day your company decided to migrate to Golang for performance reasons.

In that situation, how much of your knowledge can you transfer if you don't understand the underlying systems?

So here I have decided to put together a comprehensive list of videos

which are based on foundational concepts of a backend system.

And these are from various

There's books that I've read over the years, the open source code base.

We'll start with a very high level understanding of how backend systems work behind the scenes.

We'll look at how requests from browser flows through different hops, the network firewalls over the internet and how it is routed to our backend server

that is situated in a remote AWS server

and how it responds to the request and we'll look at what the response looks like.

And that should give us a pretty vivid idea of how systems communicate, how a client communicates with the server and how the server responds.

From there, we'll move to understanding HTTP protocol.

What is the role it plays and how the communication is established through HTTP

and how HTTP ROM messages look like and what are the HTTP headers? what are the role of the headers,

the different types of headers like request headers or representational headers, general headers and security headers.

And we'll look at different types of HTTP methods like get method,

post, put, delete and when to use them and what are the semantics and what are the principles behind them.

We'll look at what is the course flow and how does it work.

We'll look at how simple requests differs from a pre -flight request

and how a pre -flight request for looks like from our browser to the server and back to our browser.

We'll look at HTTP responses, the structure of it and different status codes that server returns

and when to return which type of code and what are the most commonly used at HTTP status codes.

Then we'll look at HTTP caching.

What are the different types of caching techniques using HTTP?

We have ETags, we have max age headers.

Then we'll look at the differences between HTTP 1 .1

and HTTP 2 .0 and HTTP 3 .0 and what are the differences between them.

We will look at how content negotiation looks like between client and server using different headers.

We'll see how persistent connections work in HTTP.

We'll look at HTTP compression, different types of compression techniques like GZIP and deflate and BR and which is the commonly used technique.

We'll see the security aspect of it, the SSL, TLS and HTTPS.

Then we'll move on to routing.

How routing maps URLs to server -side logic

and what is the connection between routing

and http methods different components of routes like path parameters

and query parameters different types of routes static routes dynamic routes nested routes hierarchical routes sketch all wildcard routes

and regular expression based routes how to do api versioning using

http different types of versioning techniques we'll see what is the best way to deprecate a route

and what are the best practices in the industry we look at the benefits of route grouping

and how it helps with version

We will see how to secure routes, how to optimize route matching performance.

Then we'll move on to serialization and deserialization.

This basically means how before sending it over to the network, our server translates the data into a particular format and after receiving the data from,

let's say client over the internet and how

and how it translates the data received from the client over the internet to its own native format.

It is called deserialization and we'll see what is the need of it

and how it helps with the interoperability standard the different formats that are used in serialization and deserialization.

We have text -based formats, which is JSON or XML.

We have binary formats, which is protobuf.

And what are the performance differences between these two and when to use which one?

We'll look at how different programming languages implement serialization and deserialization.

We will explore a popular text -based format for serialization and deserialization, which is JSON.

The structure of JSON, the different data types like strings, numbers, booleans, arrays, and objects.

How serialization of nested objects and collections are handled in JSON, how deserializing into data structures, the native data structures works like in let's say

Python dictionary or Golang structs or JavaScript object.

What are the common errors while dealing with JSON like handling missing or extra fields,

dealing with null values or date serialization issues and time zone issues

and how to implement custom serialization while before sending or serializing data into JSON.

We'll look at error handling in serialization

and deserialization for example invalid data data conversion errors unknown fields

look at the security concerns of it like injection attacks why to do validation before deserialization

and validating json schemas before processing data using json schema validation

we'll see the performance aspect of it like reducing the serialized data through compression

and eliminating unnecessary fields like serialization performance between text -based

and binary formats like json versus protobuf the trade -offs between readability

and performance because in text -based format you can easily check the payload

and see that does not work the same in binary formats

but binary formats are faster so when you use a binary format

and when you use a text -based format

that is a valid trade -off then we'll move to authentication

and authorization why do we use it different types of authentication like stateful state layers we have basic authentication, bearer token authentication, we'll look at sessions,

JWTs, cookies, we'll deep dive on OAuth protocol and OpenID Connect, we'll see how API keys work, how multi -factor authentication work,

what is salting, hashing and different cryptographic techniques used in authorization, we'll explore ABAC, RBAC, REBAC,

we'll look at what are the best practices in security like securing cookies, avoiding CSRF, XSS, MITM, audit logging,

which basically means recording authentication and authorization events for audits, and monitoring failed login attempts, privilege escalation, and access to sensitive resources.

We'll look at obfuscating authenticated related error messages, preventing information leakage to attackers through detailed error messages, and handling edge cases, for example,

100

consistency in responses across different failure modes like rate limiting and account lockout.

101

We'll see how to avoid timing attacks.

102

For example, attackers can exploit time differences in error responses to infer valid credentials. For example,

103

an error for a wrong password might take longer than an error for a valid username

104

because to check for a password you have to do some kind of hashing

105

or use some kind of cryptographic technique which takes a little bit of time.

106

So people can general the tiny bit of timing difference between them

107

and guess passwords even though that's very difficult

108

but we don't want to keep any security holes then the next topic we'll explore is validation

109

and transformation at different types of validation like syntactic validation for example checking whether a string is an email

110

or not whether it is a valid phone number or not

111

or whether it is a valid date format

112

or not there is semantic validation for example a date a date of birth cannot be in the future

113

or the age of a person should be between 1 and 120.

114

These are called semantic validations.

115

Then we have type validation.

116

For example, checking the input values match expected types, whether it is a string or not, whether it is an integer or not,

117

whether it is an array or not, whether it is an object or not.

118

These types of checks are called type validation.

119

We'll see what are the best practices for validation.

120

What is the difference between client side validation and what is the need of server side validation?

121

The importance of server -side validation even if client -side validation is already implemented

122

because client -side validation improves user experience by providing instant feedback

123

but server -side validation is the true security implementation because that is the gateway to your business logic.

124

We'll look at the importance of failing fast by reducing unnecessary processing by returning early

125

and we'll look at why to keep consistency between front -end validation and back -end validation.

126

Then there is transformations for example typecasting converting string to number or number to string because

127

in query parameters or path parameters whatever you receive is a string

128

But let's say we are expecting an ID field, which is a number.

129

So before we send it to our handlers, we have to convert that string into a number.

130

So that step is called a transformation, which we have to take care of in our validation pipeline and different date formats.

131

For example, the front end might send a different format or we might be expecting a timestamp.

132

So that also has to taken care of in the validation pipeline.

133

Then there is normalization, for example, converting an email to lowercase or trimming white space from a string or adding country code to a phone number.

134

These are called normalizations.

135

Then there is sanitization for security issues.

136

For example, we have to sanitize a string that is submitted by the user to prevent attacks like SQL injection.

137

Then there is complex validation logic.

138

For example, relationships.

139

Let's say user submitted a form and it has two fields.

140

One is password and another is confirmed password.

141

So we have to check whether the two strings are the same

142

or not so that is a relationship based validation then there is conditional validation

143

so let's say in the form there are two fields one is partner name

144

and the second is married which is a boolean true

145

or false so a partner field might only be required

146

if the married is true so that is a conditional validation

147

so these kinds of checks

148

we have to do then there is chain validation like converting a string to lower case then revoving special characters

149

and then checking its length

150

Then we'll look at error handling invalidation, like sending meaningful error messages to frontend so that the user can fix them,

151

and aggregating all validation errors in one response for client side display or obfuscating error messages.

152

So instead of saying invalid password, we'll have to say invalid credentials to prevent different types of attacks.

153

Then we'll see how to gracefully handle failed transformations, for example, an invalid JSON and a failed date conversion,

154

and how to let the user know the meaningful message.

155

Then we'll look at the performance trade -offs of validation and how to optimize it by returning early, avoiding redundant validations.

156

Then our next topic is going to be middlewares.

157

We'll look at what is a middleware and when to use them.

158

What are the common use cases of middlewares?

159

The role of a middleware in a request cycle, for example, a pre -request middleware or a post -response middleware.

160

The flow of middlewares, For example,

161

techniques like chaining a middleware is exhibited in a sequence passing control to the next middleware until request reaches its final handler.

162

How to order middleware appropriately?

163

For example, we have to go in this order.

164

We have to log the request.

165

We have to check whether the user is authenticated or not.

166

We have to do validation and we have to do route handling and then we have to do error handling.

167

So this order matters in middleware flow.

168

We'll see how the next function works in middleware and exiting middleware early.

169

How middleware can third circuit the request pipeline by handling 404 errors.

170

We'll look at some of the common middlewares like security middlewares

171

which add security headers like xcontent type or strict transport security

172

or content security policy or middlewares which add appropriate course headers to every single request or response

173

and middlewares to avoid csrf attack middlewares to rate limit

174

then we have authentication middlewares to reuse the route protecting logic across our apps.

175

Then we have logging and monitoring middlewares for request logging or structure logging for observability or easier debugging in production.

176

Then we have error handling middlewares which catches and formats application level errors for consistent API responses.

177

Then we have compression or performance related middlewares

178

which basically compresses response bodies to reduce the size of data sent over the networks.

179

Then we have data parsing middlewares, parsing incoming request bodies like json, url encoded forms

180

and file uploads handles multi -platform data for the file uploads then we'll look at the performance

181

and scalability aspect of middlewares like what are the best practices to keep middlewares lightweight

182

and efficient ensuring middleware is applied in the correct order

183

or how middleware order can affect the performance

184

and security of the application the next topic is going to be request context request context basically means the metadata

185

that is often passed through application middlewares, controllers and services.

186

It is kind of a request coped state, right?

187

The state is only valid for that request.

188

So here we'll explore the lifecycle of a request, maintaining state for the duration of a request,

189

sharing data across different layers of the application without coupling, how context provides a temporary request coped state.

190

We'll look at what are the different components of a request context, the request metadata, for example, the HTTP method, the URL headers,

191

the query parameters and the body and there is the session

192

and user information for example in the authentication middleware we fetch the user's information

193

and then we add it to the request context so for

194

that request scope the user's information is injected into the context then we have tracking

195

and logging information like unique request ids

196

or trace ids then we have request specific data like custom

197

data injected during the request life cycle like caching data permission

198

checks we'll look at what are the use cases for example

199

authentication rate limiting tracing logging we'll explore the connection between middlewares and request context.

200

We'll see what are the different types of timeouts, the request timeouts, custom timeouts, cancellation signals.

201

We'll see what are the best practices like keeping it lightweight to prevent memory overhead,

202

ensuring context data is cleaned up after request lifecycle to prevent memory leaks,

203

avoiding tightly coupling components through context or over relying on it for passing data.

204

Then we'll move to handlers and controllers, the MVC pattern and what are handlers and controllers and services,

205

the responsibilities of all of them and reducing code with middleware.

206

Then we have centralized error handling in handlers and consistent success and error message formats and how to implement them in controllers.

207

Then we'll look at the different types of CRUD operations like how CRUD operations map HTTP methods

208

and what are the common APIs associated with each method.

209

For example, POST method is usually used for creation and submissions

210

and the status code is usually 201 created or A400

211

if it's a bad request

212

and get requests are usually associated with fetching a list of resources

213

or fetching a single resource and we have put

214

and patch to update resources

215

and delete to delete resources we look at how to implement pagination

216

and how to implement a search api how to do sorting

217

and how to do filtering

218

and we'll see what are the best practices for example strict

219

validation consistent response formatting limiting payload redacting sensitive fields error handling authentication and authorization.

220

Then we'll explore what is RESTful architecture and what are the best practices for implementing REST APIs.

221

The principle of designing APIs around resources and sticking to HTTP semantics and best practices for filtering and pagination.

222

What are the different types of versioning like URI versioning, header versioning, query string, media type.

223

We'll see how to design APIs with OpenAPI spec in mind.

224

We'll see content negotiation, capturing exceptions and providing meaningful messages,

225

supporting client side caching, e -tags and optimizing large requests and responses.

226

After that, we'll move on to a very important topic which are databases.

227

In databases, we'll look at relational and non -relational, what are the differences and when to use which.

228

We'll look at some of the theoretical concepts like ACID and CAP theorem.

229

We'll take a look at basic querying and joins and database design best practices like schema design, indexing.

230

We'll look at different optimization methods like query optimization, caching, connection pooling then we have data integrity like constraints

231

and validations transactions

232

and concurrency we'll see how orms work whether to use an orm what are the trade -offs

233

and we'll look at what our database migrations to

234

that we'll move on to business logic layer

235

which is also called vll what is the role of it

236

what are the different layers of a request cycle for example

237

we have validation layer we have routing we have middlewares

238

and we have handlers and controllers which all of them fall under presentation layer

239

because they deal with users data whether it is accepting users data

240

or sending a user data so those are part of a presentation layer after

241

that we have business logic layer which is the middle one

242

which deals with our core business logic and after

243

that we have the data access layer which deals with databases performs querying

244

or inserts or deletions

245

and business logic layer uses the data access layer behind the

246

scenes we'll look different design principles like separation of concerns single

247

responsibility open close dependency inversion what are the components of a business logic layer for example

248

we have services we have domain models which represent core entities like a user

249

or an order then we have business tools

250

then we have business validation logic we'll look at service layer

251

design best practices we'll look at how to handle errors properly

252

and how to propagate those errors from our service layer to our presentation layer after

253

that we have caching we'll discuss what is the need of caching

254

and how it differs from database persistence what are the different types of caching

255

we have in -memory caching browser caching database caching

256

and what is the need of client -side caching

257

and server -side caching the different caching strategies for example cache aside right through right behind

258

or right back read through the different cache eviction strategies for example lru lfu ttl

259

and fifo need for cache invalidation like manual cache invalidation time to live invalidation or event -based invalidation.

260

The different levels of caching, level 1 which is in -memory, level 2 which is network distributed and there is the

261

hierarchical caching which combines level 1

262

and level 2 caching strategies where frequently used data is stored in a fast small cache

263

which is level 1 cache and the less frequently used data is stored in a slower

264

or large cache which is the level 2 cache.

265

We'll see how caching for web apps looks like

266

that is caching static assets

267

or caching api responses using headers we'll see how to cache

268

with databases for example query caching like storing the results of heavy joins in redis

269

and we'll look at cache hit and cache miss ratio

270

and how to optimize them after

271

that we'll move on to transactional emails what are the use

272

of them what are the common use cases the anatomy of

273

a transactional email the subject the pre -header the body header main content cta footer

274

and how to personalize with different dynamic parameters then we have task queuing

275

and scheduling what are the common use cases for example queuing might be used for sending emails

276

or processing image files and third -party api integration like payment processing or webhooks or offloading heavy computation like batch processing.

277

For example, a user clicks a button to clear all my data.

278

So to clear all the user's data, we have to call, we have to execute different queries for different tables to clear all the user's data

279

and that might take some time.

280

So instead of blocking the request, we return the response instantly and we trigger a background job by pushing into the task queue.

281

We'll look at scheduling, what are the use cases, for example, for example, running database backups,

282

recurring notifications and reminders, data synchronization or maintenance related issues, for example, clearing logs or caches,

283

the different components of a task queue, there is the producer, queue, consumer, broker, backend, the flow of a task dependency,

284

for example, it might be chain dependency or it might have parent -child relationship.

285

We look at task groups, executing multiple tasks concurrently and waiting for all of them to complete at the same time.

286

We look at how to handle errors and implement retries in task use.

287

We'll look at task prioritization and rate limiting.

288

For example, giving importance to tasks like payment processing before reprocess tasks like sending notifications.

289

After that, we'll move on to Elasticsearch.

290

Why do we use Elasticsearch and how does it work behind the scenes?

291

The different techniques that are used, for example, inverter index, term frequency and inverse document frequency, segments and shards.

292

What are the use cases of Elasticsearch?

293

For example, providing a type ahead experience or log analytics

294

or social media search for example full text search for user profiles posts comments we'll see how to create

295

and manage indexes we'll see how to search

296

and query different types of searching basic searching full text search

297

relevance scoring we'll see how to optimize search performance by tweaking text versus keyword fields understanding analyzers and boosting

298

and pagination we'll take a look at some of the advanced search patterns for example filtering aggregation fuzzy search

299

then we'll see how kibana works

300

and how to use elastic search in a user -friendly way and different best practices for example defining field mappings explicitly

301

optimizing the number of shards indexing data in batches

302

and avoiding wildcards then we have error handling the different types

303

of errors in our apps could be syntax errors runtime errors logical errors

304

and different error handling strategies for example fail safe

305

or fail fast graceful degradation

306

or prevention of errors different practices for error handling for example

307

catching early not swallowing errors custom error types failing gracefully logging errors

308

and using stack traces we'll look at how global error handlers

309

work we'll see how to appropriately handle user facing errors like providing friendly error messages

310

and providing actionable feedbacks we'll see the importance of monitoring logging in error handling

311

and different tools like sentry or elk stack

312

and different error alerts like email based alerts and slack based alerts after

313

that we have config management what is exactly config management

314

and how does it help with flexibility

315

and decouples environment specific settings from application logic and what are the use cases for example

316

different environments using config management safely managing sensitive data such as api keys database passwords

317

and private certificates dynamically enabling

318

and disabling features without changing code base what are the best

319

practices of conflict management different types of conflicts for example static conflicts like db credentials

320

and api endpoints dynamic conflicts like feature flags rate limits and sensitive conflicts like credentials tokens secrets

321

and different sources of conflicts for example it could be dot env file

322

or json or yaml and what are the differences between using environment variables versus command line flags versus static files

323

After that, we have logging, monitoring and observability, a very important topic.

324

We'll see what are the differences between logging, tracing, monitoring and observability, the different types of logging like system logging,

325

application access, security logs, the different levels of logs like debug, info, warn, error, fatal.

326

And we'll see the difference between structured logging and unstructured logging and the best practices for logging like centralized logging,

327

log rotation and retention, contextual and meaningful logs

328

and avoiding sensitive data like passwords

329

and api keys then we will look at monitoring different types

330

of monitoring like infrastructure monitoring application performance monitoring uptime monitoring the different tools

331

that are used in monitoring like prometheus grafana and how to manage alerts

332

and notifications by defining thresholds creating alerts

333

and avoiding alert fatigue by only creating actionable alerts and ensuring that alerts are meaningful and necessary

334

Then we'll take a look at observability, the three pillars of observability, which are logs, metrics and traces, the best practices around it,

335

the security and compliance of log management.

336

After that, we'll move on to graceful shutdown.

337

Why do we need graceful shutdown?

338

And how does it work behind the scenes?

339

What are the different use cases?

340

For example, you might need it when server restarts or scaling in cloud environments or microservices or long running jobs.

341

How it works, like signal handling, sigterm, sigint and kill signals.

342

What are the different steps of graceful shutdown?

343

For example, it starts with capturing a signal and then it stops accepting requests.

344

Then it completes any in -flight requests and then it closes external resources like database connections or any open files,

345

etc. And at last it terminates the app.

346

After that, we'll move on to security, the different aspects of security in a backend codebase avoiding different security attacks like SQL injection,

347

no SQL injection, XSS, CSRF, broken authentication, insecure serialization, and principles of a secure software design for example least privilege,

348

defense in depth, failed secure defaults, separation of duties, security by design.

349

Then we'll look at the importance of input validation and sanitization and rate limits and content security policy,

350

course and same -site cookie and the importance of monitoring events.

351

After that, we have scaling and performance, the different metrics of performance like response time, resource utilization, identifying bottlenecks, caching,

352

and database optimization, for example, avoiding n plus one query problems and ensuring proper use of joins and using lazy loading where appropriate.

353

Then we have using database indexes to speed up read operations on frequent query fields like indexing foreign keys or search fields,

354

how to process data in batches to minimize database load and improve performance for large datasets.

355

How to avoid memory leaks like closing file handles, database connections or cleaning up after a long process.

356

Minimizing network overhead by reducing payload size and using compression.

357

We'll look at how to do performance testing and profiling.

358

We'll look at some of the best practices for writing performance code like focusing on writing clear

359

and maintainable code first without premature optimization

360

and writing modular code to make it easier to optimize individual components without affecting the entire system ensuring

361

that if a particular resource is under load

362

or unavailable the system degrades gracefully without crashing

363

and how to offload non -critical tasks like sending emails

364

or logging to background processes

365

or task queues to free up resources for more critical operations then we have concurrency

366

and parallelism what are the difference between concurrency and parallelism

367

and how concurrency helps in io bound tasks and how parallelism helps in cpu bound tasks

368

Then we have object storage and large files.

369

We look at some of the common use cases

370

when we use object storage like AWS S3 and how to manage large files with chunking and streaming.

371

And we look at multi -part file uploads.

372

Then we have real -time backend systems where we take a look at web sockets or servers and events and pubsub architecture.

373

To that, we have testing and code quality.

374

Here we take a look at different types of testing, unit testing, integration testing, end -to -end testing, functional testing, regression testing, performance testing,

375

load and stress testing, user acceptance testing, security testing.

376

We'll take a look at what is test -driven development, how to automate tests in CICD environments,

377

how to manage code quality with external linting and formatting tools, and what are the measures of code quality and coverage,

378

like quality metrics, like cyclomatic complexity, which measures complexity of a function by counting the number of possible paths through the code.

379

And we have maintainability index, which basically quantifies how easy it is to maintain a code based on the complexity, lines of code, and other factors.

380

Then we'll take a look at a very interesting set of principles, which is called 12 -factor app.

381

After that, we'll move on to OpenAPI standards.

382

What is the need of these standards and why should we stick to it?

383

What are the benefits of it?

384

What are the use cases like documentation, automation, and the ecosystem surrounding it like Swagger,

385

core gen postman and what is the history the swagger to open api transition

386

and what are the different versions that are currently active

387

and what are the key concepts of open api documents for example there is api pass the request

388

and response definition there is parameters there is schemas

389

and what is the structure of an open api document

390

there is metadata there is paths there is components there is security definitions

391

and there is responses we'll see what are the new features of open API 3 .0 and 3 .1.

392

What are the tools surrounding open API for example swagger UI

393

core gen postman what are the best practices like avoiding duplication and sticking to standards

394

we'll look at a very interesting development method

395

which is API first development where you define your open API standard

396

or write your open API spec first and then you start creating APIs after

397

that we'll move on to webhooks what are the use cases of webhooks like sending notification third party integration

398

What are the differences between API versus webhook for the same use case?

399

For example, for API, we might have to use polling, which is client side initiated compared to webhooks, which is pushing this server initiated.

400

What are the key components of webhooks?

401

For example, the webhook URL, event triggers, payload, HTTP method, the response handling.

402

What are the best practices surrounding webhooks?

403

Like webhook signature verification by using HTTPS and quick response, retry logic, logging, How to test webhooks with ngrok

404

Real world use cases like stype payment processing, github webhooks, slack, discord, twilio etc.

405

And at last we will take a look at what are some devops concepts that backend engineers should be familiar with.

406

For example, some of the core concepts like continuous integration, continuous delivery, continuous deployment, the devops practices like infrastructure as code,

407

config management, version control, and different tools surrounding devops for example creating containers with docker

408

or orchestrating container with kubernetes and ci cd pipelines

409

and how to scale your service horizontal scaling versus vertical scaling

410

and different deployment strategies like red green deployment rolling deployment etc

411

and that's about it this is all the concepts

412

that we are going to cover in the next 30 or 40 videos so stay tuned

App downloaden

Alles wat je nodig hebt om vloeiend te spreken

AI UitspraakScoor elke zin

IPA OefeningBeheers elk geluid

WoordenschatBouw je woordenschat op

WoordenspelLeren terwijl je speelt

Scan QR

Download on theApp Store Get it onGoogle Play

FOR YOU

Aanbevolen Video

443 zinnen

Woordenschat en spreektips bij deze les

Deze spreekles is gebaseerd op de video “1. Roadmap for backend from first principles”. Deze woorden komen het vaakst terug: example, error, request, validation, middleware. Deze video bevat 412 zinnen en 5439 woorden om na te spreken. Het gesproken deel duurt 31:23. De spreker praat in een natuurlijk tempo van ongeveer 173 woorden per minuut, dicht bij een alledaags gesprek. Slechts 74% van de woorden hoort bij de 3.000 meest gebruikte Engelse woorden, dus de woordenschat is pittig.

Belangrijke woorden in deze video

15 woorden uit de video die het leren waard zijn, met uitspraak en betekenis:

Woord	Uitspraak	Betekenis
validation zelfstandig naamwoord	/ˌvæl.əˈdeɪ.ʃən/	validering
cache zelfstandig naamwoord	/kæʃ/	cache
log zelfstandig naamwoord	/lɔɡ/	boomstam, boomstronk
format zelfstandig naamwoord	/ˈfɔːɹ.mæt/	lay-out, formaat
header zelfstandig naamwoord	/ˈhɛdɚ/	kop
server zelfstandig naamwoord	/ˈsɝvɚ/	server
layer zelfstandig naamwoord	/ˈleɪ̯ɚ/	laag
database zelfstandig naamwoord	/ˈdeɪtəˌbeɪs/	database, databank
string zelfstandig naamwoord	/stɹɪŋ/	draad, koord
monitor zelfstandig naamwoord	/ˈmɑ.nɪ.tɚ/	toezichthouder
query zelfstandig naamwoord	/ˈkwɪɹ.i/	vraag, verzoek
component zelfstandig naamwoord	/kəmˈpoʊ.nənt/	onderdeel, component
password zelfstandig naamwoord	/ˈpæs.wɜɹd/	wachtwoord
alert bijvoeglijk naamwoord	/əˈlɝt/	alert, waakzaam
valid bijvoeglijk naamwoord	/ˈvælɪd/	geldig

Phrasal verbs die je zult horen

Woord	Uitspraak	Betekenis
clean up werkwoord		schoonmaken
come together werkwoord	/ˈkʌm tʊˈɡɛðɚ/	bijeenkomen, samenkomen
fall under werkwoord		vallen onder

Zinnen om te herhalen

Korte, volledige zinnen uit de video die je in alledaagse gesprekken kunt gebruiken:

How do you prioritize?
How do you see the big picture?
Then we'll move on to routing.
Then we'll move on to serialization and deserialization.
Why do we need graceful shutdown?

Grammatica in deze video

De structuren die de spreker het meest gebruikt, met de exacte woorden uit de video:

Structuur	In de video
Lijdende vorm be + voltooid deelwoord — het gaat om wat er gebeurt, niet om wie het doet	are based · is routed · is situated
Betrekkelijke bijzinnen who / which + zin — extra informatie over een persoon of ding	formats, which is · deserialization, which is · field, which is
Present perfect have/has + voltooid deelwoord — iets uit het verleden dat nu nog telt	have faced · have read · have studied

Uitspraak om op te letten

De spreker gebruikt 96 samentrekkingen en verkorte vormen, zoals we'll, don't, I've. Spreek ze kort uit, zoals je ze hoort.

De “th”-klanken: authorization /ˌɔːθəɹaɪˈzeɪʃən/, authentication /ɔːˌθɛntɪˈkeɪʃn̩/, authenticate /ɔˈθɛn.tɪ.keɪt/
De klanken “sh” en “zh”: validation /ˌvæl.əˈdeɪ.ʃən/, cache /kæʃ/, compression /kəmˈpɹɛʃ.ən/, integration /ˌɪn.tɪˈɡɹeɪ.ʃən/, injection /ɪnˈd͡ʒɛk.ʃən/
Lange woorden — let op de klemtoon: validation /ˌvæl.əˈdeɪ.ʃən/, parameter /pəˈɹæm.ə.tɚ/, integration /ˌɪn.tɪˈɡɹeɪ.ʃən/, authorization /ˌɔːθəɹaɪˈzeɪʃən/, optimization /ˌɑptəmaɪˈzeɪʃən/

Klanken die Nederlandstaligen lastig vinden:

Stemhebbende eindmedeklinker — /b/, /d/, /g/, /z/, /v/ niet verscherpen: log /lɔɡ/, password /ˈpæs.wɜɹd/, valid /ˈvælɪd/, sensitive /ˈsɛn.sɪt.ɪv/, surround /səˈɹaʊnd/
/æ/ — opener dan de Nederlandse “e”: validation /ˌvæl.əˈdeɪ.ʃən/, cache /kæʃ/, format /ˈfɔːɹ.mæt/, password /ˈpæs.wɜɹd/, parameter /pəˈɹæm.ə.tɚ/
/g/ — een harde plofklank, geen Nederlandse “g”: log /lɔɡ/, integration /ˌɪn.tɪˈɡɹeɪ.ʃən/, negotiation /nɪˌɡəʊ.ʃiˈeɪ.ʃən/, config /ˌkənˈfɪɡ/, graceful /ˈɡɹeɪsfʊl/

Zo oefen je met deze video

Luister de hele video één keer zonder te spreken en noteer de woorden die je niet kent.
Begin op 0,75× snelheid, spreek zin voor zin na en ga terug naar normale snelheid zodra het makkelijk gaat.
Neem jezelf op en vergelijk met het origineel; let daarbij op woorden als validation, cache, log.

Wat is de Shadowing-techniek?

Shadowing is een wetenschappelijk onderbouwde taalleermethode die oorspronkelijk is ontwikkeld voor professionele tolkentraining en gepopulariseerd door polyglot Dr. Alexander Arguelles. De methode is eenvoudig maar krachtig: je luistert naar native Engelse audio en herhaalt het onmiddellijk hardop — als een schaduw die de spreker volgt met slechts 1–2 seconden vertraging. In tegenstelling tot passief luisteren of grammaticadrills, dwingt shadowing je hersenen en mondspieren om echte spraakpatronen tegelijkertijd te verwerken en te reproduceren. Onderzoek toont aan dat het de uitspraaknauwkeurigheid, intonatie, ritme, verbonden spraak, luisterbegrip en spreekvaardigheid aanzienlijk verbetert — waardoor het een van de meest effectieve methoden is voor IELTS Speaking-voorbereiding en echte Engelse communicatie.

Shadowing-techniek: lees de volledige stap-voor-stap-gids →

Shadowing Practice: 1. Roadmap for backend from first principles - Learn English Speaking with Video

Kies een oefenmodus

App downloaden

Complete Roadmap for Backend Software Engineers (START HERE!)

Armchair Architects: Resiliency in the Cloud – Core Patterns

Go’s Big Mistake

How to Avoid Doing UX Theatre

System Design Was HARD - Until You Knew the Trade-Offs

How I deploy serverless containers for free

Trust the Process: How to Design Teams That Actually Work

LangChain in 5 Minutes (Explained Clearly)

How I'd Learn n8n if I had to Start Over in 2026

STOP Running Code On Your Computer

How an Agile Coach can help Product Owners

How To Land Your First Junior Dev Role