@Lui#129367 It looks like they're currently working on a refactored version of the Python SDK: https://github.com/bunq/sdk_python/commits/python-sdk-refactor

@Lui#136378 What does the community think?

An SDK changes the point of interaction with bunq from a REST API to a Python/PHP/C# library. The whole world speaks REST but nobody speaks bunq-sdk. So the SDK doesn't connect anyone to anything. The SDK is a bad idea to begin with.

On top of that, an SDK is reusable code. That is the hardest type of code to write and maintain. It's at least 5 times more expensive than regular code. It's clear bunq doesn't have the manpower to write a proper SDK, and the community doesn't have enough members to consume one.

BUNQ should drop the SDK and make the API more usable. A version that doesn't require custom headers and crypto would make the SDK redundant.

@wesselt#136667 The SDKs are generated. Only the main parts are hand written (the ApiContext for instance). The benefit of the SDK is that you end up with nice objects instead of raw JSON that you will need to parse first. Your editor then provides nice auto-completion features that can make your life a whole lot easier as a developer. An API without crypto I don't think is desirable.. It's banking data we're talking about here, bunq needs to be absolutely sure that only authorized people can access the data. 🙂

The benefit of the SDK is that you end up with nice objects

Everyone knows JSON and how to work with it. Nobody knows sdk classes or their oddities.

@Sander#136675 make your life a whole lot easier as a developer

Well, I've tried the SDK myself, and I've talked to others at the hackathon. The bunq SDK is unusually hard to use. If you want to put your money where your mouth is, install the current stable Debian and see if you can get it to work.

It's quite natural for young developers they think other people should use their code. (But not the other way around 🤣) At some point you learn that that's not how it works. The only reusable code I know is produced with sizable and continuous group efforts.

@wesselt#136689 Everyone knows JSON and how to work with it. Nobody knows sdk classes or their oddities.

I agree. But you still need to parse everything in a data structure that your system can work with. For the SDKs there's documentation, and a developer with a little bit of experience, combined with the auto completion power of the editors nowadays can easily see what's encapsulated within objects and what you can do with them. So yes, initially you might not know these SDK classes, but in practice that won't matter anyway. It just saves you quite some time when parsing the JSON data and making requests, validating things, etc. 🙂

@wesselt#136689 If you want to put your money where your mouth is, install the current stable Debian and see if you can get it to work

I would have no problem with that, but you can't really compare using that as I've seen the backend that powers the API (former bunq employee here🙈) and I've worked with that API (and the SDKS) before already. setting up the connection, that's tricky, but afterwards most things I did not even need to look at the documentation but I could simply work with the auto-completion in PhpStorm. (I work with PHP rather than Python).

@wesselt#136689 It's quite natural for young developers they think other people should use their code. (But not the other way around 🤣) At some point you learn that that's not how it works. The only reusable code I know is produced with sizable and continuous group efforts.

I've seen this claim before, and I'll give the same defense, age doesn't say anything about someone's coding skills. I've seen kids of 16 with 2 years of coding experiences produce better things than developers aged 30+ with 10+ years of experience. This might be your experience.., but you are now projecting it as a general truth, which I disagree with. Young people nowadays are taught to look at the code of others and not reinvent the wheel themselves tbh.. 🤷‍♂️ the SDK is developed by the entire bunq team, and some small parts by others. It is a (small) group effort now, and there is much to improve for sure. your claim that SDKS are a bad thing because nobody speaks "SDK", I really disagree With. 😁😉

@Sander#136715 with the auto completion power of the editors nowadays

As I remember there were editors with auto completion in the 1990s, and they got a lot better with JetBrains later on. Many C# codebases evolved right out of auto-complete editors. They endlessly copy data between different layers, each with their own strongly typed data objects. You can't do any work in these projects without an auto-complete editor.

Some people even prefer to access the database through a generated proxy layer. This results in even more copying of data and generated database queries that are impossible to troubleshoot or optimize.

Now that I'm programming in vim and Python I can see the folly of it all.

@Sander#136715 I work with PHP rather than Python

Just installing the Python SDK requires some hacks, like aliasing pip to pip3. There's always a "next" problem. I gave up after 1 hour. The PHP experience might be better.

@Sander#136715 age doesn't say anything about someone's coding skills

Well, there are some things developers consistently learn with experience. For example, I've often seen newer developers create a custom logging library that they feel everyone should use. More experienced programmers have learned why that doesn't work. Creating reusable code is much harder than you think.

@Sander#136715 your claim that SDKS are a bad thing because nobody speaks "SDK", I really disagree With

Well, how would you connect to Google Sheets? Or IFTTT?
How can you make it easier for new developers to get started with the API? 😉

@wesselt#136748

Some people even prefer to access the database through a generated proxy layer. This results in even more copying of data and generated database queries that are impossible to troubleshoot or optimize.

A proxy is either a server of a specific type, or a design pattern of a specific type. You're referring to ORMs which are, generally speaking, a good thing. Or to ActiveRecord which is generally speaking considered an anti-pattern. Neither of those are proxies.

Now that I'm programming in vim and Python I can see the folly of it all.

*rolls eyes* oh please.

Just installing the Python SDK requires some hacks, like aliasing pip to pip3. There's always a "next" problem. I gave up after 1 hour. The PHP experience might be better.

I don't know man, the SDK works fine on its own for me. It just takes a bit of Python knowhow. With a venv you don't have to alias anything and you can just type pip in your terminal. But then I don't use Vim to code, so what do I know right?

The PHP one works nicely in my experience FWIW.

I agree with Sander that age doesn't make for better coders. I've met people in their fifties who have been coding for their entire professional career and can't produce decently working code, let alone maintainable code. I also agree with you that experience helps, but it mostly helps later on when you start to see the big picture. In my experience, young people pick up best practices and architectural skills fine, the skills you pick up with age have more to do with things like communication, leadership, things of that sort.

@wesselt#136748 Some people even prefer to access the database through a generated proxy layer. This results in even more copying of data and generated database queries that are impossible to troubleshoot or optimize.

True (I assume as well you mean ORMs here). For basic use cases that is typically (more than) fine. For specific / advanced use it can also be a limitation. Depends completely on your requirements. 🙂

@wesselt#136748 There's always a "next" problem.

That's basically what software engineering is right. It's a puzzle to get it completely right. I'm not aware of such issues, I could always install the SDK with just a single command as shown on the website. But such feedback is always useful to forward to bunq such that they can potentially improve documentation / the installer.

@wesselt#136748 For example, I've often seen newer developers create a custom logging library that they feel everyone should use. More experienced programmers have learned why that doesn't work.

That's not my experience. I've seen many students and fellow developers that first try all different libraries, only when none of them work (easily) then they tend to write their own stuff,which indeed is typically of less quality than a library that has many community contributions already. But that might just be a different environment in which we both are active/working.

@wesselt#136748 Well, how would you connect to Google Sheets? Or IFTTT?
How can you make it easier for new developers to get started with the API? 😉

I don't really see how this is related. As far as I k ow you can't make use of any of the SDK languages in Google apps for instance. Then it doesn't matter whether you "speak" bunq SDK, you can't even use it. In other projects, where you can choose the language, there the SDK might be a time saver. There will always be projects where you need to do manual parsing of the JSON or where there is no SDK available in your language. 🙂 making things easier? Providing easily searchable/navigable documentation and some nice quickstart manuals I'd say. But everyone learns in a different way, so this might work for me, but not for someone else. In case you have suggestions there on how to make the python SDK easier to use then definitely let bunq know. 🙂

@Sander#136790 In case you have suggestions there on how to make the python SDK easier to use then definitely let bunq know.

Focus on actual end users. They want to put their transactions into spreadsheets, they want to connect to their accountancy software, they want to automate things with IFTTT. That's what they think when they hear "liberate your data".

That spells REST endpoint, not custom crypto, headers, or SDK. As an example of people who got it right, look at https://api.youneedabudget.com. The first sign of a good API is a curl example on the first page.

@wesselt#136808 They want to put their transactions into spreadsheets

+1

@wesselt#136808 they want to connect to their accountancy software

Many accountancy software packages already managed to integrate with the bunq API. 😁👍

@wesselt#136808 they want to automate things with IFTTT

+1, although I would argue that people would like it in the bunq app itself, but enfin, that's a different discussion. These are definitely valid use-cases, and with the right knowledge also possible in most cases.

@wesselt#136808 That spells REST endpoint

An SDK literally is just a wrapper around the REST endpoints, such that you don't have to do all the boilerplate stuff yourself. The "custom" cryptography stuff is just there as bunq is no toy, but a real bank. They need to ensure that only authorised people can make transfers. An API key can easily leak. By exchanging certificates and signing requests bunq is able to identify who's sending the requests, pretty crucial for a bank that needs to check whether someone is allowed to make a transfer. As far as I know it's still bunq who's liable in case they allow a transaction to take place because their security was not up to par. Alternatively they implemented OAuth, which is a very common standard, but in the end, bunq needs to uphold a certain level of security. The way they do it is pretty common practice; exchange keys, and then start logging in/setting up a session. Then with that session and a secured connection you can do whatever you want. Now this is also where the SDKs come into play, as they take care of all that for you. The X-Bunq-Request-Id (or whatever the name was) is there to protect you as well; it prevents replay attacks as bunq will see that the RequestId has already been used, and changing the ID is not possible as that would require a different signature, which can only be generated when you have access to the private key belonging to the exchanged public key. (long sentence, sorry)

@wesselt#136808 The first sign of a good API is a curl example on the first page.

This I reaaaaally disagree with. But, I we seem to have a different mindset on this topic anyway, so let's agree to disagree on that one. 😉 In case you consider a cURL command on the first page of the docs a measure of API quality (we were talking about the SDK though..) but nonetheless, if that's a measure for you on API quality then check out https://github.com/bunq/postman, when you load the (basic) API specification in Postman you can hit a small "Code" button, which will generate the code you need to make that particular request. From there you can also select cURL to have some cURL examples on using the API. 🙂 (it's not on the front-page, but at least you have the cURL examples) 😁

@Sander#136831 The "custom" cryptography stuff is just there as bunq is no toy, but a real bank.

Every bank supports viewing transactions over a regular https connection. Bunq does this through bunq.app. Why say you want to "liberate data" and then make the data interface unusable for most people?

In what situation does custom crypto make you more secure? AFAIK only when someone breaks https but not the custom crypto. Given that "roll your own" crypto is weaker than https, this is unlikely to happen during our lifetime.

@Sander#136831 if that's a measure for you on API quality then check out https://github.com/bunq/postman

Thanks for pointing that out, I didn't know about the Postman repository. Looks like it uses a JavaScript cryptography library. Bunq is leaving no stone unturned to push a bad idea, haha. But bunq should adopt open standards, not the other way around.

@Sander#136847 have you played with the APIs of other banks? Was it really that much easier to set up?

Haha super, I wasn't even aware other banks had APIs. Thanks for those links.

The ING link says you need a eIDAS certificate, which leads to a search that ends at https://www.toezicht.dnb.nl/2/50-235607.jsp. Looks like they don't allow hobbyist access.

@Sander#136847 ING: requires signing of requests

I was thinking about their website. I can login with a username/password and then list my transactions. Since a browser has no ING-specific code, this is not more secure than https.

@Sander#136847 What open standards are you missing then?

URL based access so you can interact with IFTTT, CSV access so you can load transactions in Google sheets. I don't know of an open standard for connecting to accounting software, but if something works for Google sheets, it is probably easy to implement for these providers.

@Sander#136847 I could spin up a webserver, install LetsEncrypt, configure HTTPS and have a secure connection, but it doesn't say anything about my identity

In fact it does tell me that you are the owner of that domain... And you are relying on this in your API because the installation call is made over regular https without signature headers anyway...

@Kwinten-Turquoise-Puma#137942 In fact it does tell me that you are the owner of that domain...

Well.. Owner... It proves you have control over the domain. Whether that's authorized or not is a second. You need the more fancy certificates (EV) to guarantee the domain truly is owned by a company if I understood things correctly. 🙂

@Lui#137970 @Sander did you get any updates?

@Lui#137970 not yet, I've asked our contact about the status just now, but it can simply take a bit before our contact hears back from his colleagues 🙂