DavorDK

The Postman data breach exposed over 30,000 APIs, uncovering critical flaws in API management. Misconfigured permissions and poor secrets management revealed vulnerabilities, emphasizing the urgent need for stronger safeguards in API development. Here’s what went wrong and how to fix it.

API Insights, launched recently, tackles API quality problems by enabling detailed review and analysis. With the addition of a CLI tool, it streamlines quality checks, integrates seamlessly into developer workflows, and promotes high-quality APIs with minimal impact on efficiency.

A great question, went into a small rabbit hole, still don't know how to answer this xD

We use Mailcoach. There is a version where you pay once for the tech, but you then need to set everything by yourself. It's great if you have the time to set it up properly.

If you are working with or building an API, Treblle has a really good free tier, plus completely free apps (no login required) - API Insights and Aspen API testing.

Might be obvious, but the Aquired guys are really good story tellers about big companies, not just tech. The podcasts where they covered Nvidia were really good. I also enjoyed the Cosnole Wars, Nintendo, Nike and NFL episodes.

What kind of API are you looking to craft?

Learn how people are building APIs and what the trends are for 2024, from the new Anatomy of an API report. It covers insights from over 1 billion requests across 10,000 production APIs about four core topics: API design, performance, security, and the overall API economy.

Some Key Findings: - AI APIs doubled in 2023 - Most API requests are made mid week - Every fifth endpoint on an API is a zombie endpoint

Not sure how would you push a Dev tool through "the business side".

Sure you can go top of funnel, still, these people are usually technical, and if they're not, they will most probably push it down the funnel so it'll end up in the Devs lap anyway.

What happens then is the Dev (most probably) will not trust it be lcause he has no reason to.

However, if the communications from that company came to him directly or indirectly through some good "problem-silving" content, then that's a different story.

Very hard to do though. Covering the top and bottom of the funnel is no easy task.

Looks pretty easy and straight forward to use. I myself use my phone for filming videos (over OBS), so I probably won't use it. I will recommend it to some of my fellow videomakers that could benefit from it, though.

An overview of API monitoring & observability with Treblle. How to set it up and what can you get out of it?

Tech Twitter is still very strong IMO. But yeah, I get that probably the most relevant stuff you could find are sites like this.

There is some useful info you can find on IndieHackers, GitHub, Stack Overflow, etc depending on what you are looking for exactly.

Could you maybe use their energy for something else? Try to refocus them by giving them other "important" stuff to work on?

Aret hey competitive? Can you maybe set out daily, weekly and/or monthly goals for them to reach (on tasks you need them to do). If they are that good and they do it all in an houre, cool, let them be free and watch Netflix or something xD

As long as the work is done (which is your goal) all is well...

It's hard to give advice since it is probably one of those "you have to be there to understand it completely", but hopefully some of this jibber-jabber helps.

But at the end of day if they're not a good fit for the work you need them to do, maybe they need to go. Maybe they'll find something their suites them better and maybe you can find people that suit you better.

Long term, everyone is happier.

If you are actively trying to find solutions to improve productivity and nothing works, maybe it's not you, it's them.

If there are still things you haven't tried, try and see what happens.

Trying to keep it simple (to a degree). First of all, I would say that its OK to still have a monolith and even build a whole product as a monolith and break it down as the need for microservices arises.

My understanding of whether or not you should take a monolith and cut it into pieces is that it depends on what you want to achieve.

Every monolith is specific, or are they? Without knowing what your product does I bet you have an API, a UI layer or two, some business logic and maybe throw emailing or a payment service. Well, guess what? We all have those!

How to decide. For myself, I’ve tried to boil it down to 3 questions:

1. Will I need to scale this part of the monolith more (often) than others? 2. Does this part of the monolith handle an entire process on its own from start to finish? 3. Does this part of the monolith require a lot of different code or resources than the other parts?

The questions are simple. They aren't philosophical. They don’t have a hidden meaning. Rather, a series of simple booleans. If something needs to be a microservice it'll most likely hit 3 out of 3 of those.

Awesome. If you need any assistance feel free to ask :)

Wow, this actually works perfectly. I searched for a theme and for a not very well known local writer I know, and got decent results.

Shared a tool with my book nerds immediately xD

After a year of closely listening to the feedback from our customers we started doing plans for our V2.

The design part is almost finished, and we are hoping to make everything live this October/November.

New Features It has a ton of new features like social logins, SSO, the ability to track external requests, new documentation portals, new design language, custom flows, an option to offload a project to a new owner, and more importantly a lot more that will help all of us handling APIops.

I've bolded the external request tracking feature because that is one of the most interesting ones to many of our customers since many of them work with other providers of APIs and have customers and suppliers of their own.

APIops Remembers this term, because it might become a new buzzword. Whether we like it or not, the world is powered by APIs right now, and more and more companies opt to have an API guy.

The term APIops already exists, but as time goes on we are guessing that it might increase in hotness :)

Try out our Interactive Prototype We are giving you access to our prototype through sketch. Everything should be clickable so you can play with it. We would love to hear your feedback!!!

Checkboard is a startup currently mostly working in the property industry in the UK, but as we’ll find out later in the talk, with big plans to expand.

Thousands of other companies use Express.js to build a REST API. How should you structure your project?

Why does structure matter? Why not use a “move fast and break things” approach and put your code wherever it seems to work?

Without good structure, it will become increasingly hard to understand your code and easier to accidentally break things. This means bugs increase and deployments become slower and riskier.

If you plan to scale your API the decisions you bake in earlier should support that. Otherwise, you’ll need to spend considerable time and expense rewriting your application.