Introduction 在後端工作中可能不時會聽到 API 太慢了能不能再快一點？ API 速度是變快了，但為什麼每次的結果都不太一樣？有點不穩定呢！ 在這些疑問之下，我們究竟面對哪些挑戰，有何種方式可以妥善處理？ Background 我們是一電商網站，因應銷售需求需要 API 來提供『百大熱門零食』的資訊。

我之前介紹過一個 MongoDB 的託管服務 MongoDB Atlas 讓我們有個免費的方案可以使用 MongoDB Cluster 進行一些 Side Project 建完資料庫就是完成了 CRUD API 一個 PostgreSQL 搞定 CRUD - PostgREST 我在裡面分享過的，當我們把資料庫建立起來的同時，也有了 REST API 可以對其進行一些基本的 CRUD 操作，而不需要在專案中依賴 DB Driver 就可以簡單地進行溝通了。 那，MongoDB 是不是也可以做到類似的操作？ MongoDB Atlas Data API

Lombok 一直是我在 Java 開發時拿來幫 POJO 減少一堆煩人的 getter, setter 時非常好用的一個 library，但有時候在設定上還是會覺得很煩，今天記錄一下又遇到了哪些設定上的問題。 前面會先提一下目前使用到的一些 feature，以及他們彼此作用後會產生的一些問題。 Immutable classes - Using @Value without lombok public class User{ private final long id; private final String name;

分享在 MongoDB 常常容易忘記，但卻很重要的事項 不會遇到 (db, colleciton) 不存在的問題 遇到 E11000 duplicate key error 的處理方式 背景 有天一樣快樂地在練習 MongoDB 的過程中，因為太心急，產生了一些錯誤，這才去細看關於 insert command 的細節 在一個 collection 內正常新增一個名字為 amy 的資料

在一開始接觸到 MongoDB 的時候發現自己塞了一筆資料進去都會看到有個 _id 的欄位出現，而且 value 看起來也不像是流水號，所以就再往裡面看了一點，想說了解一下它背後的一些知識點。 介紹 在每個 collection 中都必須有個一定要 unique value 的欄位 _id，這個欄位可以是 string, number，只需要維持 unique 的條件即可。 以下是一份 MongoDB 中的 collection { "_id": { "$oid": "56e9b39b732b6122f877fa31"

Introduction MongoDB 身為一個 NoSQL Document Database，資料會以 JSON (JavaScript Object Notation) 格式儲存在資料庫中，可以透過這樣一句指令取得其中的資料 db.getCollection("user").find({}) 基本上可以想成是這樣的 SQL select * from "user"; 回傳結果

client 與 server 之間互動最基本的形式，由 client 送出 request，server 回傳 response。 這樣的使用方式在大部分的場景下都沒有特別的問題，但如果 client 想要持續地知道 server 發生的事件，就得要不間斷地一直送出 request，否則資訊就會出現不同步。 (client 不送出 request，server 也就不會告訴 client 有沒有發生新的事件) 但如果每一個 client 都不眠不休地送出 request 只是為了知道前一秒 server 是不是有更新資料，這樣不止 client 很累，server 也需要無時無刻接受大量的 request，壓力非常的大，並且在大多數的時間，其實都沒有什麼更新的資料可以提供給 client。 現實生活 而類似的場景，在生活中畢畢皆是，假設今天我是一個軟體業的人力顧問（獵頭），以下就是我的日常。

各位 backend engineer 對於 CRUD 的粗活肯定都是非常的熟悉，雖然只是一件非常簡單的事情，但每次要做起來卻還是令人十分痛苦。 如果我們今天要以 Java Spring Boot + PostgreSQL 來寫一個最最陽春的會員系統，並且上線給大家都可以使用，就會需要以下的粗活。 Init Sprint Boot Project Init PostgreSQL Server Create "user" Table Use Sprint Data JPA Write CRUD.... Deploy Spring Boot Application 光想到我就已經想要放棄了

定義 在 JPA 定義的 Enity 中有四種關連 @ManyToOne @OneToOne @ManyToMany @OneToMany @Entity public class UserBrowsingHistory{

今天心得這篇分享源自 OWASP A02:2021 - Cryptographic Failures，對於極度機密或者是敏感的資料在傳輸上缺乏加密機制，抑或是敏感資料的存放未加密和使用一些過時的演算法。 會列出其中的一些項目，佐以實例說明，做些探討與反思。 Data transmitted in clear text 我們目前與網站之間的連線大多都為 https 與 http 連線的差異在於過程中的 message body 是有經過加密的，而每家 browser 都會在上頭加上對應的顯示，如果你的網站還在使用 http 或者是過時的加密演算法，上頭的鎖頭都會有警示，讓 end user 知道你的網站並不安全。 如果資訊傳輸的過程中沒有加密，任何攔下你封包的人都可以輕易閱讀其中的訊息，想像一下如果今天有一個服務的登入系統需要輸入帳號、密碼，而登入方式為以下這樣 http://timm.com/login?username=timm&password=timm_password

背景 我們有張 table order_history 記載著每筆訂單的付款紀錄，某天收到了一份需求，要可以很快速地取得當前付款失敗的訂單記錄，公司才可以派出債務協商業務去把錢給討回來。 限制條件：無法重構這張表的設計，也沒有權限可以開立新表，只能針對查詢做修改，或者是增減index。 orderhistory columnn type

聞風喪膽的 OOM 大多人對於下面的錯誤訊息一定不陌生 Exception in thread "main" java.lang.OutOfMemoryError: Java heap space 在一般非預期的情況下，就是有某處的程式碼一下讀取了過多的資料進到記憶體中，又或者是某個地方的迴圈沒有寫好 使用一段最簡單的程式碼來重現這個錯誤 public class Main { public static void main(String[] args) {

承接上一集，這篇想要跟大家分享的是在 stream 的操作過程中需要注意的一些眉眉角角！ 除了 try-with-resources 還有？ 這是上次說到的，操作 stream 的時候必須要使用 try-with-resources 來正確關閉 stream，還有其他坑埋在這裡面嗎？我不信！ private final UserBrowsingHistoryRepository repository; @Transactional(readOnly = true) public void sendPromotionMessage(){ try(var historyStream =

場景 需要撈取從資料庫 (MySQL) 中某個時間點以後的使用者瀏覽紀錄，並發送活動通知。但是這些紀錄量非常的龐大，經常會造成 OOM (out-of-memory)。 過程中使用到的項目是 Spring Data JPA + Hibernate MySQL @Entity public class UserBrowsingHistory{ @Id